Re: handle grapics with Document/View design

[John W. Eaton]

On 18-Aug-2005, John W. Eaton wrote:

| On 18-Aug-2005, Brian Blais wrote:
| 
| | In my implementation of the gui for octave (at 
| | http://web.bryant.edu/~bblais/octave) I have just that: an octave 
| | structure array, and there is a "handle" field.  Then I do:
| | 
| |    handles=[uiobjects.handle];
| |    idx=find(handles==h);
| | 
| | to find the actual index to the array.  It is pretty fast.
| | 
| | all of the set/get operations do the same thing.
| 
| So all the uiobjects are in a flat structure array?

Thanks for the above tip.

I've given handle graphics some more thought over the last couple of
days and written some example code that implements bare-bones versions
of

  axes  close     delete   figure  gcf  isfigure  line
  clf   closereq  drawnow  gca     get  ishandle  set

Only the minimum number of properties are handled (just enough for
proof of concept).

Everything is implemented in .m files.  I'm using gnuplot to display
the graphics and the connection is managed entirely inside the .m
files with popen/pclose.  Commands and data are sent down the pipe
with fputs and fprintf.  There are no temporary files.

On my system (a 1.4GHz AMD system running Debian) a line plot with
1000 points takes around 0.4 seconds to get on the screen.  I think
that's OK given that it is all .m files.  It will be slower if there
are more properties to handle, but maybe it will still be usable.
Performace is very bad if the number of lines approaches maybe 40 (so
you wouldn't want to create a drawing by calling line() for every
segment).  If performance is a big problem, critical sections can
always be translated to C++, but I think the real problem here is
gnuplot (you can demonstrate the poor performance running gnuplot and
plotting simple functions from the gnuplot command prompt).  In any
case, I'd prefer to keep as much as possible in the scripting
language, at least for now.

To hook up something other than gnuplot, only a few changes are
required.  The biggest thing is that you need to implement your own
drawnow function that examines the elements of the uiobjects list
corresponding to the current figure, deals with the properties, and
displays the graphics.

When GUI objects are added to the mix, we will need to think about how
events and callbacks should be handled, how to keep the GUI working
when Octave is crunching away on some computations, etc.  I haven't
worried about that much yet.

Since the list of graphics objects is just a global variable, I think
we will need some way to prevent a user from wiping it out.

If you are interested in looking at this code, it will be available
for a short time at

  http://jbrwww.che.wisc.edu/~jwe/handle-graphics.tar.gz

Unpack it, cd to the handle-graphics directory that it creates, run
Octave (it should work with 2.1.69 as well as 2.9.x), and try
something like

  line (rand (100, 1), rand (100, 1))
  drawnow
  figure (2)
  line (rand (100, 1), rand (100, 1))
  drawnow

(in most cases, you need to issue drawnow commands explicitly, since
it is not hooked in to Octave's command loop yet).

I'm sure there are some bugs, but it should at least show the kind of
design I have in mind.

Comments welcome.

jwe