Graphics windows in MCL

[gensym!thailand!bhyde@harvard.harvard.edu (Ben A. Hyde)]

Katherine Anderson wrote...
> I have found that when I have been drawing in a window using MCL, and the window 
> is hidden by any means (ie with another window, the screen saver, or window-hide),
> that the window has been cleared when it returns to the fore.  Any suggestions 
> as to how to prevent the clearing?

The short answer is that you want to implement a view-draw-contents method
for your window which redraws the entire window from scratch.  This will be
called by the MCL event handling mechanisms when it needs to be.

The long answer....

Sometimes this functionality is called a backing store.  A copy of the screen
bits is made, and when the window is exposed the screen bits are then refreshed
from that backing store.  You can illustrate this as so:
  
         Document                   Backing                Screen
 File -> Data        --Drawing-->  Store for  --refresh->  Bit
         Structure                  Drawing                Map

You can implement the backing store in hundreds of ways, and few implementors
of GUI programs agree about what the "right" approach is.  The Macintosh toolbox
leaves the design of this to you, the application builder.  There, for example,
are four popular techniques:
  1. Create an offscreen bit map in the application as a backing store.
  2. Record a PICT and then draw it when ever the refresh is requested.
  3. Just render the document again from scratch.
  4. Create a tree of objects that describe the window and draw them.
Implementing these things is interesting because in all cases you have to keep
a number of data structures in sync.

In MCL the request to refresh the screen trickles back into your application as
calls on the view-draw-contents method for the views that make up your window.

The "right" design for a view's draw method is the same design space as the
"right" design for your backing store.  The third technique is often the simplest,
just redraw the view from scratch.  

The fourth technique is popular and has some built in support for it in MCL.
If the objects in your tree are refinements of VIEW then 
MCL's event dispatching machinery will feed the events to the
appropriate objects.  That's a help when you start to give mouse behavior to
your window's contents.  In this scenario the picture of your architecture looks
something like this:
   Document                Tree
     in      -open/read->   of   -refresh-> screen
    File                   Views
The nodes in the tree might be paragraphs, ICONs, words, even characters.

The second technique "Record a PICT" has a number of interesting variations.
One is to just record a MAC PICT, this can be very fast on refresh, but it
is subtle to figure how to make incremental changes to a PICT when you make
changes to the underlying document data structure.

Another variant of the "Record a PICT" technique is to build a set of objects
that can be uses as the tree of objects/views is in scenario four.
In this scenario the architecture looks something like this:
          Document                         Transcript
 File  ->   in     -"draw"&record output-> of drawing         -refresh-> Screen
           Core                            with backpointers
                                           to document
This, to greatly simplify a rich system's architecture, is the CLIM approach.

Hope this helps.

- ben hyde, gensym inc. aka bhyde@gensym.com