home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text1153.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  2.0 KB
  1. Received: from ppsw3.cam.ac.uk (mauve.csi.cam.ac.uk [131.111.8.38]) by nacm.com (8.6.10/8.6.9) with ESMTP id HAA16739 for <executor@nacm.com>; Tue, 9 May 1995 07:35:18 -0700
  2. Received: from mole.bio.cam.ac.uk by mauve.csi.cam.ac.uk 
  3.           with SMTP-CAM (XTPP8.1) as ppsw.cam.ac.uk;
  4.           Tue, 9 May 1995 15:34:14 +0100
  5. Received:  from localhost 
  6.           by mole.bio.cam.ac.uk (931110.SGI/MDTG-V1.3@mole.bio.cam.ac.uk)    id AA12312;
  7.           Tue, 9 May 95 15:38:11 +0100
  8. Message-Id: <9505091438.AA12312@mole.bio.cam.ac.uk>
  9. To: ctm@ardi.com (Clifford Thomas Matthews)
  10. Cc: executor@nacm.com
  11. Subject: Re: status report 
  12. In-Reply-To: Your message of "Tue, 09 May 1995 01:09:00 MDT."             <m0s8jQA-00000BC@beaut.ardi.com> 
  13. Date: Tue, 09 May 1995 15:38:10 +0100
  14. From: Tim Cutts (Zoology) <tjrc1@mole.bio.cam.ac.uk>
  15. Sender: owner-executor@nacm.com
  16. Precedence: bulk
  17.  
  18. In your message (Tue, 9 May 95 01:09 MDT), you wrote:
  19. >1.99n is *at least* a week away.
  20. >
  21. >Mat is in the middle of his new blitter mods, so he needs to finish up
  22. >his work before we can begin testing what will become 1.99n.  There
  23. >are also a variety of bug fixes that we need to make before we can
  24. >release 1.99n.
  25. >
  26. >The reason only some Linux users are finding 1.99m to be ridiculously
  27. >slow is related to some new cursor handling code we put in.  Some Mac
  28. >applications frequently (once through the event loop, for instance)
  29. >set the cursor to the same value.  Executor used to detect this
  30. >special case and ignore these extra calls.  However, 1.99m doesn't
  31. >ignore them, it passes the calls right on to the low-level cursor
  32. >manipulating code, which results in *a lot* of traffic between
  33. >Executor and the X-server.  If the traffic is done via shared memory,
  34. >it doesn't affect things too much, but if you can't use shared memory
  35. >(say you're using an X-terminal), then you lose big time.
  36.  
  37. I'm not sure I agree with this.  I find some apps almost completely 
  38. unuseable even using MITSHM on the local console.
  39.  
  40. Tim.
  41.  
  42.  
  43.