home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text2191.txt < prev    next >
Encoding:
Text File  |  1996-03-31  |  3.0 KB  |  64 lines
  1. Content-Transfer-Encoding: 7bit
  2. Content-Length: 2864      
  3. Sender: owner-paper@nacm.com
  4. Precedence: bulk
  5.  
  6. Mat Hostetter writes:
  7. > 
  8. > Many Mac apps that track the cursor location make frequent calls to
  9. > reset the cursor bitmap, and usually they just keep resetting the
  10. > cursor to the same thing.  In the black-and-white Executor days, we
  11. > would detect when the cursor bitmap wasn't really changing and avoid
  12. > the overhead of telling the window server to change the cursor.  When
  13. > we added color cursor support, we no longer made that check.  So the
  14. > end result was zillions of calls to the X server to keep (redundantly)
  15. > setting the cursor over and over again.
  16. > 
  17. > We never noticed this problem on our machines, but apparently the
  18. > cursor flicker is irritating on other machines.  We have fixed this
  19. > problem (in theory), and the fix will be present in 1.99n.
  20. > 
  21. > -Mat
  22.  
  23. Hi,
  24.  
  25. The problem was actually a transition between a cursor that could be
  26. rendered in hardware and one that must be rendered in software.  When
  27. we detected the change, we flipped from H/W to S/W and then as soon
  28. as we found that the cursor could be presented in hardware, we
  29. flipped back again.  On each transition, we lost a little memory in a
  30. true leak (allocated memory twice, to the same variable, with no
  31. intervening free() - duh!).  The high rate of flipping between
  32. cursors could cause a 16MB growth in about one hour.  We fixed this.
  33.  
  34. I'm mildly surprised that a performance difference was detected.  I
  35. suspect that this has more to do with another, coincident change, to
  36. eliminate a pathological allocator/garbage collector condition, that
  37. could cause a lossless memory growth (all memory was accounted for,
  38. no leak, but a particular series of calls to the allocator could
  39. upset the garbage collector and prevent the arena from being
  40. correctly coalesced).  Correcting this algorithmic error did lead to
  41. about 5% performance loss in the memory allocator, which would
  42. translate to a couple of %age points in overall code execution with 
  43. heavy memory allocation.
  44.  
  45. I'm glad that's it is fixed in 1.99n (whetever that is) but I'm also
  46. grateful that it existed in whatever the prior release was.  Changing
  47. cursor types between hardware renderable and software renderable
  48. forms is sufficiently rare that this bug may have been in our code for 
  49. a long time, without us having any significant clue. ;-)
  50.  
  51. I'd like to add executor to our set of manual tests.  Is there a
  52. particularly good application that will exercise the display
  53. technology?  I assume that there's also an extensive "HOW-TO"
  54. somewhere... Since we don't run Macs at all, I have absolutely no
  55. idea what is involved.
  56.  
  57. Cheers, JeremyC.
  58. -- 
  59. Jeremy Chatfield  +1(303)470-5302  FAX:+1(303)470-5513  email:jdc@xinside.com
  60.         Commercial X Products - for more information please try:
  61.         X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA.
  62. http://www.xinside.com/        majordomo@xinside.com          ftp.xinside.com
  63.  
  64.