Re: patch to configure.in & aclocal.m4 for graphics libraries

[David Bateman]

Shai Ayal wrote:
> On 9/15/07, David Bateman <address@hidden> wrote:
>> Michael Goffioul wrote:
>>> On 9/15/07, Shai Ayal <address@hidden> wrote:
>>>>> Does this mean that at some point, octplot (or a derived product)
>>>>> will become the de-facto standard graphic backend of octave?
>>>> The plan is to include a renderer in the octave distribution. It will
>>>> be based on the octplot rendering code with modifications to handle
>>>> 3D. All the object tree management will be done by the octave
>>>> object/property code which is already in place and has no connection
>>>> with octplot.
>>>> Use of different renderers could be facilitated by a "renderer"
>>>> property for each figure which would determine which renderer would
>>>> render the figure. This way you could have several figures each
>>>> rendered by a different renderer.
>>> If octave comes with an integrated graphics backend with decent
>>> features, I don't really see the point of continuing developing JHandles,
>>> as nobody will use it anyway (why would you install and use a 3rd
>>> party backend, if you have already one that works). Having choice
>>> is not always what the user wants: he just wants something that
>>> works. And as John pointed out, it's a spreading of resources.
>>> I'll then re-think my commitment to JHandles.
>>>
>>> Michael.
>>>
>> Shai,
>>
>> When and by who was such a decision made? Yes I've seen comments that
>> gnuplot just doesn't cut it and should go, but what exactly it'll be
>> replaced with I've seen no final decision.
>>
>> That being said, I'd personally love to see as much as possible of the
>> handle system itself in octave core sooner rather than later, Frankly
>> what is there now is incomplete at best. Michael has been working on a
>> number of the missing features (barseries, areaseries, etc) in jhandles
>> and it would be if as much as possible of that also when into the core,
>> Equally, I'd love to see some of the specialized plots (quiver, pie etc)
>> that are part of octplot included, though till gnuplot is dumped that
>> probably means writing backends for gnuplot as well.
> 
> This is where we are going. I have began to make a renderer to plot
> the octave object tree. The main reason I began is that no-one else
> was doing it. I am desperate for help especially since octplot was 2D
> only (I don't like 3D) and I have no experience in 3D.
> I am not locked-in on any specific back-end, although it seems to me
> that it's pretty natural for it to use OpenGL (all the backends
> written in the last 5 years were based on it) since 3D is a
> requirement.

Jhandles is based on JOGL, so its a java wrapper around OpenGL.

> I decided to start with FLTK as the widget library since I like that
> it is small, light and cross platform and I have experience
> programming it from octplot. However I am open for suggestions.
> It is my opinion that octave core should not be dependant on java --
> in my experience it is very bloated and causes you to spend your
> valuable CPU/Memory resources on things not directly related to the
> tasks you want to achieve in octave.

When I was a teenager my first machine had 8kB, with my current machine
has 2GB, and I expect it to grow permanently, any memory restriction is
only transitory. All other points being equal, it is of course
important. However what are the advantages and disadvantages of the
alternative renderers, I can imagine that its not impossible that some
other advantage might outweigh any memory requirements.

> 
>> The final decision on what renderer to include in the core should be
>> made after 3.0..
>>
>> D.
>>
>> PS: I also agree with Michael that when a compatible renderer is in the
>> core the others will be a dead-end
> 
> I almost agree. This is the main reason I decided to freeze octplot
> development and start developing the core renderer.
> However if a renderer is compatible and has advantages, I think it is
> viable -- look at matplotlib which has several back-ends. As an
> example, I think that for 2D plots, OpenGL+gl2ps (which is used by
> both octplot and jhandles) really sucks, and a much better approach
> would be to use libcairo -- images would look much better, and
> off-screen rendering would be very easy to implement. If there was a
> backend based on cairo I would use it. And I might even write it one
> day. Remember -- all that this is is a renderer -- it takes the object
> tree and draws it. It doesn't have to be too sophisticated and it
> would be easy to add new ones
> 

In fact this to me is the crux of the issue with jhandles (and octplot
as it stands at the moment). There is no clean split between the graphic
handles in octave and the backends. Its probably easy to deal with this
issue for octplot than jhandles.

Yes I agree that opengl+gl2ps is ugly and for plotting in octave gnuplot
is still the only way to go (the graceplot interface seems a deadend).
Given your statement above, it seems inevitable that there will be at
least to different renderers. So the important thing now should be to
get the frontend right and the API to the backend fixed.. Bill Denney I
believe worked on an API (found on the wiki), but the split between the
backend and frontend is not clear.

D.