From graphics-request at octave dot org Tue Jul 12 14:09:29 2005
Subject: handle graphics
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: octave maintainers mailing list <maintainers at octave dot org>
cc: octave graphics and gui mailing list <graphics at octave dot org>
Date: Tue, 12 Jul 2005 15:05:09 -0400

[I'm copying this to the graphics list, but since that is mostly
dormant now, I'd prefer to discuss this on the maintainers list, so
please reply there.  --jwe]

Is anyone actively working on implementing handle graphics for Octave?

I've been thinking about this recently.  My first thought was to
create a structure array to describe the figure windows.  For example,
something like

  figures, a 1-d structure array.  Each element of the structure
           array would contain all the information for a given figure
           window and would contain the following fields:

    title

    ...

    subplots, a 2-d structure array.  Each element of the structure
              array would contain all the information for a given
              subplot.

      axis, a 1-d structure array.  Each element of the structure
            array would contain all the information about the given
            axis (element 1 is the x axis, element 2 is the y axis,
            etc.) and would contain the following fields:

        label
        tics
        ...

      line, a 1-d struct array.  Each element of the structure array
            would contain all the information about the given line in
            the subplot and would contain the following fields:

        style
        width
        label
        data
        ...

This data structure would be stored in a global variable and would be
manipulated by the various plotting functions.  For example, if the
first plotting command were

  plot (x, sin(x))
           
then the global structure would be initialized to default values and
filled in with the data for a single figure window with a single
subplot area (filling the window).  The data for the sin(x) curve
would be stored in the structure along with the plot description.  If
the next command were

  legend ("sin(x)");

then the data structure would be modified to store "sin(x)" as the
label for the first line of the current plot and the current figure
would be redrawn given the data in the structure.

Using this, we could implement various graphics backends, but all
would share the same common set of functions to manipulate the global
data structure that describes the state of the figures on the screen.
Experimenting with various backends would be fairly easy (you would
really only need to implement the function that takes the global data
structure and displays it on the screen).  I imagine that it might
even be possible to implement a backend using gnuplot.

Next, I started looking at the properties for Matlab handle graphics
so that I could see whether this could be done entirely in M-files or
whether we would need a custom data structure and functions written in
C++.  I was hoping to be able to do it all in M-files because it might
be simpler to implement and debug.  Unfortunately, it doesn't seem
that it would be easy to do.  For example, a call like

  set (h, 'property', value)

changes the value of the 'property' field in the data structure
pointed to by the handle h.  So we can't pass the actual data
structure around (because of the call-by-value semantics of
Matlab/Octave).  It seems that Matlab graphics handles are some kind
of pointer value encoded in a double object.  Using only the scripting
language, how can we use something like that to lookup the location in
a complex structure array?  One possibility would be that each
graphics handle object type would have a ID field, and we could
traverse the global data structure looking for the ID that matches.
But that is likely to be slow.  Any ideas?

Thanks,

jwe