[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: handle graphics

From: jswensen
Subject: Re: handle graphics
Date: Wed, 13 Jul 2005 12:25:49 -0600
User-agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.10

I actually started a few months back on a handle graphics implementation as
native Octave types.  I didn't get a lot of it coded, but had the design
basically done.  Mine was tied intrinsically to GTKMM, but this didn't seem to
be a problem as I did my simple test on Cygwin(with X), Linux, and OSX. Basically, here is how I designed the implementation.

Every handle type derives from a base 'handle' class which in turn derives from
'octave_base_value'.  The 'handle' class defines two static STL maps of
<string,funcptr_get_property_handler> and <string,funptr_set_property_handler>.
  For a given class, this map is filled with the property names and their
associated handler member function.  Since I didn't have time to implement all
of them at the time, the 'handle' class has a default
unimplemented_set_property_handler and unimplemented_get_property_handler.

My initial tests only implemented the 'figure' class with the ability to set the
size and title.  I also implemented a 'uicontrol' (only with label and button
capabilities) to prove I could place it on the 'figure'.

I think my design should be good with one exception, caused by GTKMM. It has no
way of re-ording widgets, other than removing them an placing them on the
container again in the desired order.  This kindof looks weird (causes the
screen to flicker), but I figure the changing the z-order of widgets is not a
common thing to be done after startup.

With respects to plotting, I had talked with maintainer of the Octave<->VTK
plotting stuff and intended to use the VTKCanvas addon to GTKMM to do plotting.
This handles both 2D and 3D graphs quite well.

If anyone is interested in helping/continuing my work, I will send them what I
have so far.  I just got really busy at work and haven't touched it in about 4
months.  I had intended on showing it once I had a few handle objects fully
implemented (or nearly-fully implemented), but haven't got around to it.  I
think the design I gave will allow random people to implement unimplemented
properties, without breaking existing functionality.

I would appreciate anyone's comments on both the design and to measure the level
of interest.

John Swensen

Quoting "John W. Eaton" <address@hidden>:

[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:



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

     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:


     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:


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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]