Path: utzoo!utgpu!watmath!att!bellcore!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!uakari.primate.wisc.edu!indri!aplcen!haven!umd5!zben
From: zben@umd5.umd.edu (Ben Cranston)
Newsgroups: comp.sys.mac.programmer
Subject: MultiFinder rationing background update events?
Message-ID: <5181@umd5.umd.edu>
Date: 8 Aug 89 22:28:00 GMT
Organization: University of Maryland, College Park
Lines: 36

For several weeks I've been playing with breaking an expensive screen update
operation into many smaller "chunks" by using the update region stuff.  More
specifically, when I get an update event I do some small part of the update
drawing and then (AFTER BeginUpdate) make an explicit call to invalidate the
"rest of the work" (what was invalid before minus what was just drawn).

When my application is not the foreground application I get some strange
behavior.  Some small part of the updating (perhaps a few tens of separate
update events) actually get done, then drawing suddenly ceases.  If I then
uncover more of the window, another small piece of the drawing is done, etc.
My application is far too simple to explain this behavior.

The only explanation I can think of is some MF heuristic must be coming into
play.  When a non-foreground application's window is un-obscured it must give
the application some bounded number of update events in which to reduce the
window's update region to empty.  If, after that number of update events, the
update region is still not empty, MF must be arbitrarily clearing out the
update region and moving on to the next un-obscured window.  Parenthetically
it seems to refuse to do anything else (like menu operations or window select)
while this process is going on.  This looks like a peculiarity of the way MF
itself is programmed.

I've developed two work-arounds.  One is to do more work in each chunk, so
that all the drawing can be finished in the ration MF is giving me.  The other
is to maintain my own independant update region (which I am already doing for
other reasons; mail me if you want an explanation) and during idle event
processing re-invalidate the area that still needs to be drawn.  Unfortunately
both these approaches largely invalidate the reasons I did this kluge in the
first place - to let the user do other things before the time-consuming
update operation fully completes.

Has anybody else seen this behavior (i.e. is this a known MF "feature")?
-- 
Sig     DS.L    ('ZBen')       ; Ben Cranston 
* Computer Science Center Network Infrastructures Group
* University of Maryland at College Park