zben@umd5.umd.edu (Ben Cranston) (08/09/89)
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 <zben@umd2.UMD.EDU>
* Computer Science Center Network Infrastructures Group
* University of Maryland at College Parkgoldman@apple.com (Phil Goldman) (08/09/89)
In article <5181@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: > 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. Yes. The problem is that many apps will simply not update their windows in certain situations. Therefore, since context switching is relatively expensive, MultiFinder provides a maximum number of tries that it will give an app to update in the background. The number of tries allowed was chosen as to be large enough so that legitimate updating could occur in pieces; I believe the number is somewhere around 50. If you find that you must do more than a few pieces then you should do exactly what you mentioned in your posting: Clear the update and keep your own region. To do this you will have to be a background app too. -Phil Goldman Apple Computer