Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.95/text2186.txt

Internet Message Format | 1996-03-31 | 3.6 KB

Received: (from jdc@localhost) by crab.xinside.com (8.6.8/8.6.9) id JAA02561; Mon, 19 Jun 1995 09:44:53 -0600
From: Jeremy Chatfield <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Linux executor help
To: [e-mail] (Mat Hostetter)
Date: Mon, 19 Jun 1995 09:44:52 -0600 (MDT)
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]> from "Mat Hostetter" at Jun 19, 95 08:25:00 am
Organization: X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA.
Phone: [phone]
Reply-To: [e-mail]
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2864
Sender: [e-mail]
Precedence: bulk

Mat Hostetter writes:
>
> Many Mac apps that track the cursor location make frequent calls to
> reset the cursor bitmap, and usually they just keep resetting the
> cursor to the same thing.  In the black-and-white Executor days, we
> would detect when the cursor bitmap wasn't really changing and avoid
> the overhead of telling the window server to change the cursor.  When
> we added color cursor support, we no longer made that check.  So the
> end result was zillions of calls to the X server to keep (redundantly)
> setting the cursor over and over again.
>
> We never noticed this problem on our machines, but apparently the
> cursor flicker is irritating on other machines.  We have fixed this
> problem (in theory), and the fix will be present in 1.99n.
>
> -Mat

Hi,

The problem was actually a transition between a cursor that could be
rendered in hardware and one that must be rendered in software.  When
we detected the change, we flipped from H/W to S/W and then as soon
as we found that the cursor could be presented in hardware, we
flipped back again.  On each transition, we lost a little memory in a
true leak (allocated memory twice, to the same variable, with no
intervening free() - duh!).  The high rate of flipping between
cursors could cause a 16MB growth in about one hour.  We fixed this.

I'm mildly surprised that a performance difference was detected.  I
suspect that this has more to do with another, coincident change, to
eliminate a pathological allocator/garbage collector condition, that
could cause a lossless memory growth (all memory was accounted for,
no leak, but a particular series of calls to the allocator could
upset the garbage collector and prevent the arena from being
correctly coalesced).  Correcting this algorithmic error did lead to
about 5% performance loss in the memory allocator, which would
translate to a couple of %age points in overall code execution with
heavy memory allocation.

I'm glad that's it is fixed in 1.99n (whetever that is) but I'm also
grateful that it existed in whatever the prior release was.  Changing
cursor types between hardware renderable and software renderable
forms is sufficiently rare that this bug may have been in our code for
a long time, without us having any significant clue. ;-)

I'd like to add executor to our set of manual tests.  Is there a
particularly good application that will exercise the display
technology?  I assume that there's also an extensive "HOW-TO"
somewhere... Since we don't run Macs at all, I have absolutely no
idea what is involved.

Cheers, JeremyC.
--
Jeremy Chatfield  [phone]  FAX:[phone]  email:[e-mail]
        Commercial X Products - for more information please try:
        X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA.
http://www.xinside.com/        [e-mail]          ftp.xinside.com