Re: graphics-branch in CVS

[Shai Ayal]

On 12/7/06, John W. Eaton <address@hidden> wrote:
[snip ....]
> I chose to continue with this code rather than adopt something like
> OctPlot because OctPlot does not do 3d graphics.

Ouch :)
This is true, but octplot uses OpenGL for plotting, and this design
choice was made specifically so that 3D could be added "easily" --
OpenGL should take care of all the hard things like hidden
lines/surfaces and might even give us hardware acceleration.
Anyway, I am not a big fan of 3D, so I put it quite low on my priority
list. However if someone is willing to help it shouldn't be that hard
(famous last words ...).
I think you'll find an extremely friendly project admin -- I grant
subversion write access very quickly and try to reply within a week
although octplot is just my hobby, not my day job.

> 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).

Octplot does have a very large portion of the plotting functions
converted to use handle graphics, so you could use them

> 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.
>
> Some limitations (I'm probably missing a few things):
>
>   * The drawnow function is not hooked in to the interpreter yet, so
>     you may have to issue a drawnow command to see changes applied to
>     the current figure.  We will need to be able to mark graphics
>     objects with a timestamp so we can quickly decide whether drawnow
>     really needs to do anything.
>
>   * The image function has not been converted, so image display is
>     completely broken.
>
>   * The axis function has not been converted.  When the axis limits
>     are autoscaled by gnuplot, Octave doesn't really have a reasonable
>     way to ask gnuplot what it chose for the limits, so it is not
>     possible to use the axis fucntion to ask for the limits after a
>     plot command.  Is it important to have this feature?  If so, then
>     maybe Octave needs to determine the limits on its own and pass
>     them to gnuplot?  If we did this, then the axis function could
>     work reliably.

I think one important feature is the ability to control the placement
of ticks and control the ticklabels

>   * The contour function has not been converted.

     you have a ready made contour function in octplot

>   * There is not much checking to ensure that properties have valid
>     values, so things will likely break for bad input.  This must be
>     fixed eventually, but I don't see it as a high priority now.
>
>   * It is slow.  Some of this can probably be fixed by translating the
>     core code that deals with the list of graphics handles to C++.  It
>     may also be necessary to convert the code that processes the plot
>     data structure and interacts with gnuplot.

Also, keeping all the data in octave ans sending it to gnuplot each
time could be very time consuming -- when plotting large datasets it
would be very annoying. I think for the future plotting backend some
sort of shared memory scheme should be implemented, although I have no
idea how to do it. This would allow both octave to force a redraw on
changed data and the backend to redraw independently (i.e. because of
window resize etc...) without keeping 2 copies of the whole graphics
data tree. I think there was a project named CMO which implemented
this kind of shared memory in octave.

>   * Not all plot properties are completely compatible with Matlab.
>     For example, to display the plot legend, Matlab seems to draw a
>     mini plot, and stores all the grphics objects necessary for that
>     as children of the current axis object.  The new code in Octave
>     just stores info that a key is needed, along with some information
>     about the labels, and lets gnuplot generate the plot legend.
>
> jwe