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

[Shai Ayal]

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

> 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