[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC project: new graphics backend
From: |
Arseniy Lartsev |
Subject: |
Re: GSoC project: new graphics backend |
Date: |
Sun, 29 Mar 2009 16:45:28 +0400 |
User-agent: |
KMail/1.10.3 (Linux/2.6.27.19-3.2-default; KDE/4.1.3; i686; ; ) |
On Sunday 29 March 2009 16:13:08 Michael Goffioul wrote:
> To be honest, I'm not convinced you would gain anything and I don't
> see the added value:
>
> - you're adding yet another layer in the rendering process, which
> will probably have an impact on the speed
It will take one extra microsecond to render each plot.
> - while this seems pretty easy in the case of a line, I don't think
> this will still be the case for complex objects like transparent
> shaded surfaces
Less simple, but still not too complicated.
> - in the sample above, you want to perform the graphic transformation
> yourself; so you'll loose any hardware acceleration advantage in OpenGL
I don't quite understand what you mean, could you please explain more details
to me?
>
> - in some cases, you can implement rendering optimization
> techniques by rendering a graphical object as a whole, instead of
> only being given fragments of it
I don't know in what situation it might happen.
> - I understand what you're trying to do, by trying to have a renderer
> object as simple as possible, such that it's easier to add a new one,
> but I think that in the end, you'll loose efficiency, while there might
> be 2 or 3 actual renderers required or implemented
>
> IMO I don't think we should go further in the granularity (or level of
> refinement) of the renderer object. I'd be much more enthousiast if
> you'd be willing to implement a renderer based on the existing
> code structure; for instance, I'm convinced that a cairo backend
> would provide much nicer 2D plots than OpenGL, and is almost
> as much toolkit agnostic as OpenGL.
This approach has exactly one disadvantage: I'll have to duplicate some code
of existing renderer in my rendering module. If Octave graphic-related data
structures get changed, same changes will have to be done to each renderer,
and it can be quite difficult for me to change my renderer properly.
But if I get convinced that this is a relatively minor problem, I can give up
the idea of abstract renderer.
signature.asc
Description: This is a digitally signed message part.
- Re: GSoC project: new graphics backend, (continued)
- 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
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/29
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/29
- Re: GSoC project: new graphics backend,
Arseniy Lartsev <=
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/29
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/30
- Re: GSoC project: new graphics backend, Przemek Klosowski, 2009/03/30
Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/22
Re: GSoC project: new graphics backend, Jonathan Stickel, 2009/03/26