Re: graphics-branch in CVS

[John W. Eaton]

On  7-Dec-2006, David Bateman wrote:

| John W. Eaton wrote:
| > 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.
| 
| There seems to be some other things that might be taken from Bill's
| code, with the most notable being patch.m...

Yes, except that as far as I know, Bill's code only sets property
values and doesn't actually generate the plots, so I think code to
handle actually drawing this kind of graphics object would need to be
added.

| > 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.
| 
| One minor thing I'd like to see changed is to separate the backend
| directory. My reasoning is that although not strictly needed to
| implement another non gnuplot backend, if not all of the backend
| functions are implemented then an rmpath on the backend directory will
| prevent a remnant of a gnuplot backend function doing something
| unexpected. Then again the backend developer can always supply dummy
| functions for all backend functions.

Eventually, OK.  For now, I'm more interested in getting the current
code working to the point that we can make a new 2.9.x snapshot or
two.  The biggest problem was speed of the interpreted code, but I
think that is fixed now.  The slowness was mostly due to having the
shared global variables in a script file.  That caused trouble because
the script file was being interpreted every time a function like set()
or get() was called, and those are called a lot.  So doing some
preprocessing to pasted the script directly into the .m files that
need the global variables makes things run at an acceptable speed (at
least for use as a prototype).  I checked in the changes for this on
the branch.  We can probably still speed things up by writing some
C++, but I think that can be left for later (or not at all, if
something like OctPlot can be used instead (but it will have to have
3D plotting before it can be the default plotting engine for Octave).

jwe