octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: graphics and OpenGL rendering


From: Michael Goffioul
Subject: Re: graphics and OpenGL rendering
Date: Thu, 27 Dec 2007 22:30:53 +0100

On 12/27/07, Shai Ayal <address@hidden> wrote:
> Michael, you seem to be on top of this, and your code, once converted
> to c++, will be able to do almost everything needed, so maybe we
> should make it the basis for the backend code, while I will
> concentrate on adding properties and adding types to properties in
> octave, and also on adding FLTK support ?

If it's OK for you, that's fine for me. However, converting the full code
can take a while (+/- one month). Adding all properties (even if they
are not used) and using typed properties is a priority for me, because
it has an impact on how the rendering code should access and use
property values. Besides that, while working on it, a few things came
to my mind:
1) it seems there's not mechanism to have hidden properties; this is
handy to store (in the graphics objects) data that could be used by
any backend, but that should not be used by the user; typical example
is the the transformation matrices (Matlab also does this)
2) I'm currently testing the rendering code outside octave, so I need
a couple of exported symbols; I think these symbols will be needed
anyway by any 3rd-party backend, so it's good to export them; see
attached patch
3) default axes color is black; it think it should be white
4) we should integrate ASAP a scaling/ticking algorithm, like the one
proposed in another thread (it's not perfect, but it's already a good start
and it should work OK in all "normal" cases); for the moment, tick arrays
are empty and I need to set them manually to see something in the
rendering code
5) axes should have a reasonable default "position" property: this is
needed to compute the transformation matrices
6) do you think the separation between graphics_renderer and
gl_graphics_renderer is useful? My idea is that there could also be
other renderers, like a cairo_graphics_renderer; hence I used a base
class to put all the common stuff
7) I guess there should be some synchronization mechanism between
the octave code and the rendering code; in Java, the rendering occurs
in a separate thread (the event-loop thread). Some mutex is probably
needed to avoid race condition.

Michael.

Attachment: graphics.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]