[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC project: new graphics backend
From: |
Michael Goffioul |
Subject: |
Re: GSoC project: new graphics backend |
Date: |
Sun, 29 Mar 2009 13:13:08 +0100 |
On Sun, Mar 29, 2009 at 8:10 AM, Arseniy Lartsev <address@hidden> wrote:
>> Am I mistaken, or what you mean is taking the current "draw()" interface of
>> opengl_renderer class and put it into an abstract class, and make
>> opengl_renderer
>> inherit from it?
> Yes. It would look like this:
>
> class abstract_renderer {
> ...
> void abstract_renderer::draw (const line::properties& props);
> virtual void draw_line(const Matrix &x, const Matrix &y, const Matrix &z)=0;
> ...
> };
>
> class opengl_renderer: public abstract_renderer {
> ...
> virtual void draw_line(const Matrix &x, const Matrix &y, const Matrix &z);
> ...
> };
>
> void abstract_renderer::draw (const line::properties& props)
> {
> Matrix x = xform.xscale (props.get_xdata ().matrix_value ());
> Matrix y = xform.yscale (props.get_ydata ().matrix_value ());
> Matrix z = xform.zscale (props.get_zdata ().matrix_value ());
> draw_line(x, y, z);
> }
>
> void opengl_renderer::draw_line(const Matrix &x, const Matrix &y,
> const Matrix &z)
> {
> glFoo();
> glBar();
> ...
> }
>
> Of course, there should also be line width, color, style, etc.
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
- 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
- in the sample above, you want to perform the graphic transformation
yourself; so you'll loose any hardware acceleration advantage in OpenGL
- 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 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.
Michael.
- Re: GSoC project: new graphics backend, (continued)
- 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
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/29
- Re: GSoC project: new graphics backend,
Michael Goffioul <=
- 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, 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