Re: [Graphics] OpenGL code integration

[Michael Goffioul]

On Fri, Feb 1, 2008 at 7:45 AM, John W. Eaton <address@hidden> wrote:
> | > 1) port the complete renderer before integrating it into octave:
> | > this probably means you won't see any code before 2-3 months.
> | >
> | > 2) send patches on the mailnig list for early integration in octave:
> | > patches would then be produced when rendering of a new object
> | > has been completely converted.
> | >
> | > 3) wait for SCM switch before doing anything and work on a local
> | > repository (maybe with a public archive, such that John can
> | > pull changes regularly).
> |
> | I would go with this option, but only if the SCM change happens soon.
> | option 1 is a bit too drastic, and option 2 is not very good since
> | OpenGL is not enough -- who will open the window? you need some
> | toolkit.
>
> Although I hope we can move away from CVS soon, I can't promise that
> it will happen within a short time (like say, this week), so I would
> be happy to go with 2 for now.
>
> I'm assuming the functions you will be adding will be independent of
> the current gnuplot backend, so there shouldn't be any signficant
> stability problems caused by doing this.  If not, then we could always
> open a branch for it.

I does not have an impact on the existing gnuplot backend. The OpenGL
renderer is put into a new class (opengl_renderer) into a new file. It has
an indirect impact on the graphics code, because sometimes I'm missing
some functionalities. Also, if this code is integrated, some additional
configure magic should be used to determine when to compile it (because
it requires OpenGL).

OTOH, if the SCM switch is happening soon (< few months), then I can
continue to port and test the code locally (option 1). Then I'll use option 3
when a new SCM is available. I think it's the easiest for everybody.

Michael.