Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!new
From: new@udel.edu (Darren New)
Newsgroups: comp.sys.amiga
Subject: Re: Layers speed (was Re: 1.4 Wish: Revamped sizing gadget)
Message-ID: <2063@nigel.udel.EDU>
Date: 19 Oct 89 15:13:10 GMT
References: <5028@cps3xx.UUCP> <5682@cbnewsm.ATT.COM>
Sender: usenet@udel.EDU
Reply-To: new@udel.edu (Darren New)
Distribution: na
Organization: University of Delaware
Lines: 23

In article <5682@cbnewsm.ATT.COM> nsw@cbnewsm.ATT.COM (Neil Weinstock) writes:
>In article <5028@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes:
>[ ... ]
>>On the very few occainsions that I have used a Mac, having a lot
>>of windows open did not really slow things down, som its gotta
>Can't get any slower...

Actually, I think it does get much slower, but the "premptive" (sp?) nature
of the Mac "inner loop" keeps you from noticing.  Basically, when you get window
damage, a simple flag is set in the window structure.  Later, if you ask
for input (i.e., input events are generated only when you call GetMsg())
and there is no real input, the window list is scanned from front to back
looking for damage flags and the "input event" returned is a refresh event.
Hence, if you damage a bunch of windows, you can still type right away;
you just won't get updated back windows.  This becomes most evident in
the finder when you close bunches of windows; they don't update before
they close.

This is also nice because key-repeat does not "run away" if you hold the key down.
Basically, if you ask for input, it generates a key repeat only if the key
is still down and at least X time has elapsed since last time it returned 
the key.  Hence, if the program does not look at the keyboard, the keys
don't repeat.  Too bad this is hard to do on the Amiga. -- Darren