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