Re: graphics future (was: Re: color_radio_property implementation)

[Michael Goffioul]

On 4/26/07, John W. Eaton <address@hidden> wrote:
> I know very little about Java, and have never written a Java program.
>
> Whatever we decide, I think it is important to have one implementation
> for Octave that we all work together to improve rather than splitting
> out efforts.
>
> Also, I simply don't have the cycles to be the maintainer of the
> graphics code.  I took my best shot at the property database code for
> 2.9.10.  If people think that is a reasonable design and someone would
> like to maintain and extend it, then OK.  If not, then let's agree on
> something else that is maintainable, extensible, and (perhaps most
> importantly) compatible.
>
> Also, at this point, I think gnuplot as a graphics rendering backend
> is a dead end.  I just don't think that gnuplot works well as a
> low-level plotter, and it is a lot of work to translate the property
> data into gnuplot commands and make it all (sort of) work out in a
> compatible way.  In addition, I don't see much hope for being able to
> insert programmable GUI objects in a gnuplot graphics window and have
> the kind of two-way communication with Octave that is necessary to
> handle graphics and GUI features.

[Sorry for the long mail]

I didn't mean or intend to replace any existing solution. Actually, I started
on this because I had my java interface and I wondered "Now, what can
I do with it?", then I found JMathLib and JOGL. I got enthusiat and this lead
me farer than I thought at the beginning.

Now, I think that a little diversity is OK (even good). Too much is indeed
a waste of resources. Concerning gnuplot, I think it's main advantage is that
it works (for many basic plotting things) and has a bunch of output formats.
I wouldn't drop it, but I wouldn't put too much effort in it due to its inherent
limitations (no GUI, speed (you have to re-transfer everything if you just want
to change the line color), 2-way communications...).

The other main possibilities are octplot, yapso and oplot-gl (my code; maybe
less advanced at user-level, but I think I have a solid more advanced
core base).
Deciding on the way to go is unfortunately a never-ending debate. OTOH, these
3 solutions are all based on OpenGL. So, beside the fact they use different
languages or toolkit, the core of the problem, which is rendering, can
be largely
shared: maybe not at code-level, but at least at idea-level. For instance, the
way I setup the view transformation in order to fit the window can be re-used
in octplot or yapso. Or I could also re-use the octplot's algorithm to compute
nice autoscale in my java code (there's none at the moment). Moreover, the
complete user-level m-code part can probably be shared. In this context, even
having 3 backends doesn't seem such a waste of resources.

Now, let me give some pros and cons for a java-based solution.

cons:
- additional dependency on Java: although I guess Java is installed on most
computers, it's still a dependency (octplot depends on FLTK and FREETYPE2,
yapso depends on GLUT (not standard under Windows))
- speed and memory footprint: this is the same debate as whether develop in
native C/C++ or in bytecode languages like Java; with the increasing performance
of today's computer, this is less a problem; BUT it's still an issue on older
hardware

pros:
- cross-platform: Java is available for most computers out there; and the
"develop/compile once, run everywhere" reduces the development effort
- large pool of existing development tools: for instance, java GUI is natively
threaded, I didn't need to do anything for this and I could run my code
within octave process without any effort (this speeds up the communication
between octave and the graphics backend)
- GUI objects available

Bye,
Michael.