Re: GSoC project: new graphics backend

[Michael Goffioul]

On Sun, Mar 29, 2009 at 1:45 PM, Arseniy Lartsev <address@hidden> wrote:
>> - 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.

I don't think this will still be in the order of a microsecond when
rendering thousands of shaded transparent quads; the overhead
of calling virtual functions to change the color, transparency,
lighting for each vertex might become significant. But I agree that
in simple cases, this won't be a problem.

>> - 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?

I just misread your sample, sorry. You can ignore my comment.

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

If I wanted to be picky, I'd say that in the above comment you're only
talking about some more work for *you*. But in the end, you'll come with
a quite complex interface for the abstract renderer, in order to support all
the bits and pieces required for rendering lines, surfaces, patches... and
support shading, lighting, transparency... (in Qt world, the interface would
probably be similar to QPainter)

Yes, another renderer will probably have some similar code as the
OpenGL renderer (there's no 1000 ways to render a line), and there's
probably some room for code factorization (I'm especially thinking about
the axes object, which is composed of multiple objects, like axes box,
ticks, grid lines...). But frankly speaking, how many renderer do you think
there will be? Maybe 2 or 3? Just be sure to have the best trade-off between
efficiency, complexity and some code duplication.

Michael.