[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
- Re: GSoC project: new graphics backend, (continued)
- Re: GSoC project: new graphics backend, Eric S. Carlson, 2009/03/22
- Re: GSoC project: new graphics backend, Ben Abbott, 2009/03/22
- Re: GSoC project: new graphics backend, Søren Hauberg, 2009/03/22
- Re: GSoC project: new graphics backend, Eric S. Carlson, 2009/03/22
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/23
- Re: GSoC project: new graphics backend, Eric S. Carlson, 2009/03/24
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/26
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/26
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/27
- Re: GSoC project: new graphics backend,
Shai Ayal <=
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, Shai Ayal, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, John W. Eaton, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/28
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/28