Inter-Office Memorandum
    To          Cedar Interest        Date    January 3, 1983
    From    Mik Lamming and Glen Williams    Location    Palo Alto
    Subject    Graphics Lists        Organization    PARC/ISL
    XEROX
    Filed on:    [Indigo]<ISL>Documentation>GraphicsLists.Tioga
    Documents:    [Indigo]<ISL>Top>GL.df.
    The Graphics Lists Package
    Introduction
        Generating an image involves two steps: computing that image and displaying it.  Graphics lists provide a mechanism for saving the 
        computed image.   They are useful when images that are computationally expensive to generate are frequently reimaged  
        Another use may be to use a list to drive a hardcopy generator.  A list can be generated in one succession of "graphics 
        calls" or piecemeal.
        
        This document is intended for people or automata familiar with Cedar Graphics.
    Useage
        To display an image in Cedar Graphics, one calls one of a number of procedures to control imaging, say to set clipping windows and 
        to actually draw objects.  A graphics list is generated with exactly the same sequence of Cedar Graphics calls as if the 
        image were being displayed to the screen.  In the latter case, a regular graphics context is used; in the former a special 
        context is used.
        
        The user obtains a graphics list context from the graphics list package using the Start function.  Having called that, the 
        user can call procedures in the Cedar Graphics package with the new context, and the calls are saved on the list.  When the 
        user has created as much of the image he cares to for that list, he may call End.  End returns a list handle.  Thus,  one 
        can have a list that creates the body of a person, and another list that creates a hat.  Then, the person with a hat can be 
        created on the screen by calling GL.Draw twice, once for each graphics list.  You can call Start with a list you created 
        earlier: this causes subsequent objects to be appended to the list.
        
        As mentioned in the Introduction, a nice feature of graphics lists is their device independence.  Therefore the same list 
        can be output to a variety of devices.
        
        It should be noted that, as an image is being built in a graphics list, it is not displayed onto the output device.  Also, 
        none of the information in the context is saved, such as the fat flag, the current transformation, and the clipper. The 
        information is available and consistent as you build the list. We also don't do anything with DrawBits.
        
        So, there are three procedures in the interface: Start, End and Draw.
        
        Wish list:
            Can't store these things on a file.
            Can't let lists refer to other lists.
            Can't do Cedar Graphics-style nested save and restore (can only do one level).