Re: [OctDev] Java/OpenGL-based graphics package for octave

[Michael Goffioul]

On 4/23/07, David Bateman <address@hidden> wrote:
> Just a comment on the src/Makefile, which contains
>
> <quote>
> CLASSPATH = jogl.jar:/usr/local/octave-vc8-debug/forge/java/octave.jar
>
> all: oplot-gl.jar
>
> oplot-gl.jar:
>        javac -cp $(CLASSPATH) -source 1.2 -target 1.2
> org/octave/graphics/*.java
>        jar cf oplot-gl.jar org/octave/graphics/*.class
> </quote>
>
> You can't hard-code the CLASSPATH in that manner. Maybe you need a
> configure script to probe what this value should be. Furthermore I'd
> suggest modifying the all target to be

Don't pay too much attention to the Makefile. I wrote it quickly to provide
something that's compatible with pkg.m. But in the end, I also include the
compiled jar file into the package archive (as Java-code is cross-platform)
such that a user does not need JDK (which is usually the case).
Hardcoding is not a final solution, but I didn't want to spend time now on
writing configure test for finding JOGL and other java-related stuff (I also
might relocate the octave.jar archive from the java interface package).

However, putting the JAR files into the bin directory is a nice idea. That
should ease the loading of JVM.

> I also don't think the high level plotting functions such as
> stem, surf, image, legend, etc should be touched (though surf isn't in
> octave yet), but rather only the code that is called after a drawnow, to
> have a simple separation between the graphics front-end and back-end.
> This might mean that there are some frontend changes you need, but the
> front-end code definitely shouldn't have java specific code in it. This
> goes equally for patch and light which should be in the front-end with
> appropriate objects in
> src/graphics.cc and then only rendered into java in the backend.

I did it when it was possible (I overloaded some of the __go__*
functions). But sometimes it was not, because the function did not
exist (patch, light, surf) or it was too different from the Matlab-way of
doing (stem, legend).

For instance, a legend in Matlab is a complete independent axes object
which is a regular child of the figure (you can even set its view to 3D mode),
while in octave it's a set of properties spread between the axes object and
the line objects (Matlab does not jave "key", "keypos" or "keylabel"
properties).

I also agree that there should be a clear separation between the front-end
and the back-end (the front-end should be "java-free"). However this also
means that the front-end should be flexible enough for various types of
back-end and keep the auto-computed things at minimum. For instance,
in stem, I don't want the front-end to compute the xdata/ydata values and
create the baseline, I'll do it myself (I insert NaN's between stem lines and
the baseline is a special object). But all this will become clearer when other
backends will pops up.

> In any case Michael, this is great and I even if it is only Windows,
> intgerate it with your MSVC build and it might well become the most used
> octave graphics backend of all..

It's far from finished. But I wanted to give other the opportunity to test it
and get some comments. Also, it's better to work on the front-end in
cooperation with octave development (that's why I didn't spend time on
the front-end functions and just use quick-and-dirty dedicated functions
for testing purpose; I knew it would need to be rewritten for better integration
with octave).

Michael.