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

[Shai Ayal]

On 9/15/07, David Bateman <address@hidden> wrote:
> 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.

well while I started out the same as you in memory terms, my current
machine only has 256MB of memory, and I'd hate to use it all up on
java.
>
> >
> >> 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.

octplot is just as dependant on it's internal object tree as jhandles
is in on it's tree. This is why I am writing a NEW renderer based on
the octplot plotting code.

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

Bill Denney worked on defining the minimal set of objects/properties
that should be supported by a backend. Now that octave has it's own
object tree, I think this has become the de-facto minimal set of
objects/properties. We should work to add in as many
objects/properties as possible of course.
As for the API for backends, It is in development now and consists of
accesor functions for objects/poperties. Some other parts are missing
(listners etc...) and I would be happy for some contributions.

Shai



> D.
>
>