octave-maintainers
[Top][All Lists]
Advanced

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

Re: GSoC project: new graphics backend


From: Shai Ayal
Subject: Re: GSoC project: new graphics backend
Date: Sat, 28 Mar 2009 09:06:09 +0300

On Fri, Mar 27, 2009 at 7:45 PM, Arseniy Lartsev <address@hidden> wrote:
> On Thursday 26 March 2009 18:30:06 John W. Eaton wrote:
>> I'm not sure that we want to add vtk as a dependency for Octave, at
>> least not by default.
>>
>> I don't think that graphics is something that should be done in add-on
>> packages for Octave.  It seems to me that people will expect graphics
>> to work more or less the same in all versions of Octave, regardless of
>> the OS they are using.  That's why we have been working to add
>> graphics properties and an OpenGL renderer to Octave.  If you want to
>> help improve graphics in Octave, then please help us to improve the
>> existing OpenGL renderer.
> Fine, I can use this renderer. But good renderer is not enough, what I need is
> integrating plotting system into IDE with convenient GUI. I'm going to start
> it as a separate backend, but it could be included into Octave source tree at
> any time (though I doubt that developers will agree to add Qt as a dependency
> for Octave).
>
> By the way, I looked into the code of this OpenGL renderer and saw that going
> through Octave's internal graphic-related data structures is not separated
> from the actual rendering, so there's no easy way to replace OpenGL based
> rendering with something else. So, what about splitting this renderer into two
> parts: the renderer itself which does not know anything about Octave data
> structures and provides some API, and universal rendering module that walks
> through data structures and leaves actual rendering for the other module? I
> could do this.
>

The way it works today is that octave-core is in charge of maintaining
the graphic object tree and the opengl-renderer is in charge of
rendering the tree. The fltk backend is in charge of the periphery of
the figures (i.e. user intraction, buttons, zoom etc...), but uses the
opengl-renderer to render the actual figure.
>From what I understand, you would probably want to replace the fltk
backend with something that is based on QT. This would not entail any
changes to the opengl-renderer -- you would just use it to render
inside your Qt window.
I do not think that further separation is possible between
opengl-renderer and octave -- the really basic operations (line,
patch, point etc...) are provided by OpenGL. Anything above that is
closely coupled to the octave object tree.

Shai



reply via email to

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