ViewerWishesJunk.tioga --- Stolfi May 24, 1984 4:54:10 pm PDT

III. Moreover, a system-generated call to the PaintProc may sneak in between two client calls, and ask for the entire image to be repainted. If the image is created or modified by the various "chunks" in an incremental fashion, then the client must invent some internal representation for the image --- a "display file" --- and update that data structure inside the PaintProc.

There is generally a tradeoff between the size of each "chunk" and the complexity of the display file. Breaking the execution in large chunks may allow a more compact dispaly file, since global repainting can be restricted to happen in fewer and simpler states. For example, if the execution consists of a single chunk, we are back to solution I, and the display file is not needed. In the other limiting case, each graphics command is made into a separate chunk, so the display file is like a generalized Imager.Trajectory. While this idea has the merit of being general, it is too space-consuming for many applications.

Indeed, there may be no way to partition the execution into chunks that are at the same time short enough to avoid the deadlock problem, and long eneough to allow a compact display file. In any case, the programming effort that goes into designing and updating such specialized display files is generally much more than what goes into solving the problem proper. This solution obscures not only the structure of the program, but also that of its data.

IV. If no suitable compromise can be found, then the client might try to update the display file in the main program, and then call the PaintProc to paint the affected parts on the screen. This will be an improvement only in a very few cases, and it requires acess to the display file to be controlled by a separate lock, with all the corresponding costs and dangers.

V. Finally, the client might consider painting into a private bitmap (which may be considered to be a special case of a display file), and arranging for the PaintProc to copy this bitmap onto the screen at suitable intervals. This solution is relatively simple to implement: the client ``only'' has to import a dozen interfaces, fork two processes, sinchronize them with the vertical retrace and the WindowManager, and do some minor fiddling with monitor locks and condition variables.

Things get more complicated if the client decides to scale the image and/or dimension the bitmap so as to fit the current size of the viewer. To do this, the client must call the PaintProc with a special argument, telling it to allocate the bitmap instead of blting it onto the screen. If the rescaling is to happen whenever the Viewer moves, then system-generated calls to PaintProc should do nothing but set a global flag. The client should check this flag ???

As far as I know,