Solution (1) is generally bad, as it locks half the world for the duration of the program. In the "orthodox" solution (2), the programmer has to design and implement a suitable data structure (a "display file") that represents the current state of the image, and whose purpose is to satisfy the system-generated calls to the PaintProc. In my experience, this is not a trivial undertaking. When I implemented some Voronoi diagram algorithms in Cedar, a couple years ago, I found that implementing the display file took much more programming effort than coding the algorithm proper. Another problem with this approach is that the flow of control shuttles into and out of the PaintProc in a way that would make a BASIC programmer shudder of joy.

Solution (3) has less adverse impact on the structure of the program, but can be considered "simple" only by comparison with (2). To use it you have to import a dozen interfaces, fork two processes, synchronize them with the Window manager and the screen raster, and control their access to the bitmap via a monitor lock. If you also want to scale your image according to the window size, and be able to paint it also on the color monitor, that will probably require as much messy code as (2). This assuming, of course, that you have memory to spare for an extra color bitmap.

I. Bitmap Buffer Made Official. The first proposal is to implement the bitmap-buffer method (3) as the standard Viewers interface. ViewerOps.Create automatically allocates a bitmap buffer, and returns a context for it. Graphics commands write onto the buffer, and set a "bitmap changed" flag that is interrogated and reset by the screen bitbltting process. The dimensions of the bitmap may be either client-specified or equal to the initial size of the viewer.

When the viewer changes size on the screen, the bitmap is NOT reallocated; the old one continues to be displayed, clipped and/or padded to the new window size. The implementation may provide standard mouse commands for two-dimensional scrolling of the bitmap under the window.

There could be a client option telling the bitbltter to magnify or shrink the image in the buffer (by sampling) so as to fit the current window. This has to be done after each graphics command, however, and I guess we don't have enough computational power to do it.

The interface should allow the client to obtain the current size of the window on the screen, and to replace the bitmap buffer by a new, blank one of specified dimensions. This allows the client to repaint the whole image in a scale fitted to the current window size --- if and when it deems convenient to do so.

For added convenience, there could be an option (set, say, at viewer's creation time) that causes all graphics routines to raise a signal if the window size has changed since the previous graphics command. The client can use this signal to interrupt any painting or computation in progress, resize the bitmap, and repaint the current image from scratch . This would require some sort of a "display file", but it is not worse than (2), and may to allow more structured handling of these exceptions.

If the user moves a viewer to a device with different resolution, color encoding, or pixel format, the bitblting of the current bitmap onto the screen has to be either disabled, or performed in whatever crude way that is fast enough to do in real time, until the client notices the change and re-alocates the bitmap. Therefore, it seems better for the window manager to pass all "move to color display" requests to the client, rather than perform them right away.

II. Direct Screen Painting. The idea here is to let the client paint directly on the screen bitmap. As before, creating a viewer returns a context that stays around all the time. That context describes the current window on the screen. When the window moves, the image in the old window is bitblted to the new one, clipped and/or padded with background color as appropriate. The context is altered so as to point to the new window; its clipping box is set to that of the new window, but its user/device transformation is NOT changed. Each graphics command must momentarily acquire the screen lock to do its painting.

The positioning of the image in the new window is determined by the viewer's coordinate sustem. I suggest extending the current {top | bottom} choices to both axes independently, and add a "centering" option: {left | vert.centered | right}x{top | hor.centered | bottom}. (By the way, I find it confusing for the "top" coordinate system to have the y axis pointing down. I much prefer to have consistent directions, and deal with negative coordinates.)

The problem with this schema, of course, is that expanding a window will not make the hidden portion of the image visible --- only graphics commands executed after the move will paint into the new space. In particular, if the viewer is closed and re-opened, the old image is completely lost.

As in the previous proposal, we could consider magnifying or shrinking the old image by sampling (and scaling the user-to-device transform accordingly), instead of clipping it. This idea is now feasible, since the sampling has to be done only when the viewer moves, but the partial alleviation it gives may still not be worth the trouble.

Sampling and/or color conversion are necessary in any case if the viewer is moved to a device with different resolution, color encoding, or pixel format. The problem is less demanding here than in the Bitmap Buffer schema, since the mapping has to be done only once per move. Alternatively, we may channel all requests for device changes through the client, and let it worry about repainting the image in the new window.

As in the Bitmap Buffer schema, there will be tools for the client to obtain the current size of the window on the screen, change the user-to-device transformation of the context, and repaint the whole image in the desired scale --- if and when it deems convenient to do so. The option for the graphics routines to raise a signal upon detecting a window change could also be implemented.