home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text2183.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  2.3 KB

  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id HAA08961 for <executor@nacm.com>; Mon, 19 Jun 1995 07:26:01 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id IAA19578; Mon, 19 Jun 1995 08:25:57 -0600
  3. Received: from gwar.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0sNhlL-000YbmC; Mon, 19 Jun 95 08:25 MDT
  5. Received: by gwar.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0sNhlL-000GOkC; Mon, 19 Jun 95 08:25 MDT
  7. Message-Id: <m0sNhlL-000GOkC@gwar.ardi.com>
  8. Date: Mon, 19 Jun 95 08:25 MDT
  9. From: mat@ardi.com (Mat Hostetter)
  10. To: kemp@convex.convex.com (Phil Kemp)
  11. Cc: executor@nacm.com, jdc@xinside.com
  12. Subject: Re: Linux executor help 
  13. In-Reply-To: <9506191253.AA20093@convex1.convex.com>
  14. References: <9506191253.AA20093@convex1.convex.com>
  15. Sender: owner-paper@nacm.com
  16. Precedence: bulk
  17.  
  18. >>>>> "Phil" == Phil Kemp <kemp@convex.convex.com> writes:
  19.  
  20.     Phil> I had some really nasty problems with executor under linux
  21.     Phil> using the xinside. After extensive testing the xinside folks
  22.     Phil> determined that the something in executor was eating memory
  23.     Phil> like crazy. It seems to me that Thomas said something about
  24.     Phil> the cursor code having memory holes. I've copied the xinside
  25.     Phil> for further comments.
  26.  
  27.     Phil> The xinside folks were able to fix this on the server end
  28.     Phil> with a slight performance reduction( ~1 or 2 percent)
  29.  
  30.     Phil> Sounds like the executor folks might want to pursue this
  31.     Phil> further.
  32.  
  33. Many Mac apps that track the cursor location make frequent calls to
  34. reset the cursor bitmap, and usually they just keep resetting the
  35. cursor to the same thing.  In the black-and-white Executor days, we
  36. would detect when the cursor bitmap wasn't really changing and avoid
  37. the overhead of telling the window server to change the cursor.  When
  38. we added color cursor support, we no longer made that check.  So the
  39. end result was zillions of calls to the X server to keep (redundantly)
  40. setting the cursor over and over again.
  41.  
  42. We never noticed this problem on our machines, but apparently the
  43. cursor flicker is irritating on other machines.  We have fixed this
  44. problem (in theory), and the fix will be present in 1.99n.
  45.  
  46. -Mat
  47.  
  48.