Re: Oplot a backend for Octave

[Shai Ayal]

On Thu, Jan 7, 2010 at 6:25 PM, Søren Hauberg <address@hidden> wrote:
> tor, 07 01 2010 kl. 06:57 -0800, skrev Ole Jacob Hagen:
>> I am developing a graphical backend to octave named Oplot.
>> Oplot can plot most of graphical objects using opengl_renderer. I can also
>> rotate, pan and zoom on Oplot. I can also rotate, pan and zoom on a selected
>> axes object even I have multiple axes in one figure (a subplot).

Ole, It's been a long time since I last heard from you. Welcome back !

>> Oplot is based on Qt4, which can be compiled with mingw or MSVC on windows.
>> Is there any msvc and mingw compiled octave-3.3-50 out there?
>
> Does this utilise the current OpenGL code which is used by the FLTK
> backend? In general, how does Oplot relate to the FLTK backend?

Since Oplot is using the opengl_renderer, it is utilising the current
OpenGL code.
both Oplot and FLTK are the GUI around the OpenGL "canvas" which is
rendered using opengl_renderer.
So, you could say Oplot and FLTK backend stand on equal footing.

>
>> I can also create jpeg, png images of plots using Qt's builtin
>> functionality. An example is shown here:
>> http://old.nabble.com/file/p27061261/sombrero_subplot.png
>
> It should be possible to render the OpenGL plots to a buffer in memory,
> and then write this buffer to disk using the image writing capabilities
> already present in Octave (via GraphicsMagick). This way, it would be
> possible to share this feature with other backends.

off-screen rendering is a key feature. The situation today is that
off-screen rendering is only supported by gnuplot, which means e.g.
the manual figures can only be produced with gnuplot.
The ideal would be for this to be in a special backend w/o any need
for GUI (after all, who needs a GUI when there is no screen?). In
practice this is hard to do cross-platform. When writing the GUI we
rely on some external framework to take care of all the cross platform
stuff for us (FTLK or Qt). If we want to write a backend which does
not rely on any GUI framework, we have to do all the cross-platform
stuff ourselves. (e.g. initialize the OpenGL context, initialize an
off-screen buffer are all OS dependent processes).
This is hard (for me at least).

>> Why does print.m use gnuplot related commands? This means that gnuplot is
>> mandatory as a installation during file generation with print.m! Shouldn't
>> the backend fix the printing functionality?
>> Shouldn't gnuplot just be a backend, and not the primary application for
>> file generation of figures?
>
> The work on the graphics backends is still work-in-progress. The OpenGL
> code only recently got preliminary support for printing, so there hasn't
> been a great incentive to make 'print' backend specific. I'm sure
> patches will be accepted, though :-)
>
>> I'm planning on releasing Oplot shortly on both Linux (32, 64 bit), and
>> Windows (32 and 64).
>> Oplot will be released after I've added more functionality to the gui, and
>> this is tested. ;-)
>> But I believe that Oplot should be released after 0ctave-3.4.0 has been
>> released. ;-)
>
> Why not work on integrating your work with Octave (I assume your code is
> GPL?) ?

I'm not sure you want octave to depend on Qt. While it is available on
all platforms, it is rather big. The main advantage of FLTK is it's
small size.

Shai