graphics-branch in CVS

[John W. Eaton]

I created a separate CVS branch called graphics-branch for the code
that I've been working on.  Check that out if you'd like to see what
direction I'm heading in.

The previous code was moving toward storing the complete data for all
figures in a set of global data structures, all indexed by the current
figure and subplot location, etc.  This approach was quickly becoming
unmanageable, and was just not going to work for some things.

The new version rearranges that data structure so it looks more like
Matlab Handle Graphics (TM) objects.  Everything is still implemented
in .m files, so it is somewhat slow.  The current code is primarily
derived from what I announced on this list:

  http://velveeta.che.wisc.edu/octave/lists/octave-maintainers/2005/853

along with some ideas and code from Bill Denney's version.

I chose to continue with this code rather than adopt something like
OctPlot because OctPlot does not do 3d graphics.

For this latest revision, I've only implemented the properties that
are necessary for the graphics functions we currently have in Octave
(see below for some things that are not yet working).

I think of this code as an intermediate solution to graphics problems
in Octave.  It gives us a path forward so that at least some handle
graphics code written for Matlab can work in Octave, and it should
allow us to solve some long-standing problems with plotting.  For
example, we should be able to plot 2d figures on top of images, make
the print function work for subplots, and (with a little more work)
allow line widths and styles to be set.

Some limitations (I'm probably missing a few things):

  * The drawnow function is not hooked in to the interpreter yet, so
    you may have to issue a drawnow command to see changes applied to
    the current figure.  We will need to be able to mark graphics
    objects with a timestamp so we can quickly decide whether drawnow
    really needs to do anything.

  * The image function has not been converted, so image display is
    completely broken.

  * The axis function has not been converted.  When the axis limits
    are autoscaled by gnuplot, Octave doesn't really have a reasonable
    way to ask gnuplot what it chose for the limits, so it is not
    possible to use the axis fucntion to ask for the limits after a
    plot command.  Is it important to have this feature?  If so, then
    maybe Octave needs to determine the limits on its own and pass
    them to gnuplot?  If we did this, then the axis function could
    work reliably.

  * The contour function has not been converted.

  * There is not much checking to ensure that properties have valid
    values, so things will likely break for bad input.  This must be
    fixed eventually, but I don't see it as a high priority now.

  * It is slow.  Some of this can probably be fixed by translating the
    core code that deals with the list of graphics handles to C++.  It
    may also be necessary to convert the code that processes the plot
    data structure and interacts with gnuplot.

  * Not all plot properties are completely compatible with Matlab.
    For example, to display the plot legend, Matlab seems to draw a
    mini plot, and stores all the grphics objects necessary for that
    as children of the current axis object.  The new code in Octave
    just stores info that a key is needed, along with some information
    about the labels, and lets gnuplot generate the plot legend.

jwe