Re: handle graphics

[Shai Ayal]

John,

Octplot is active (well, at least not dormant) and so is oplot I
think. They both implement handle graphics. There is also CMO, which
is a bit more abstract.

The way I implement handle graphics in octplot is to make distinction
between objects (figure,axes,line ....) and properties (color,
position, width ....), just like matlab.

So each object has a unique handle and through it you can access all
it's properties. To support the hierarchy of objects, each objects
also has a "parent" property and might have "children" properties,
holding the handles of parent/children.

My code is a stand-alone application accepting commands through a
socket connection with octave, since at the time I didn't have time to
delve into the mysteries of octave c++ implementation. In retrospect
it was probably a mistake.

In your proposal there is no clear distinction between object and
properties, in a sense everything is a property of the "root". This is
a nice idea, but incompatible with matlab where an object has an
handle and properties don't have one. This kind of structure can be
coerced on your proposed structure by denoting some properties as
special and giving direct access to them using a handle (i.e. all
figures will have handles, but the titles won't). As usual matlab
compatibility makes us use less than optimal coding.

Stated your way the whole graphics back-end becomes a rendering issue,
like the document/view style of programming where the structure is the
document and and the back-end is a viewer. I like it.

Shai Ayal

On 7/12/05, John W. Eaton <address@hidden> wrote:
> [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
> 
>