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: 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.



reply via email to

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