[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [Gnash-dev] Questions about trapezoids, triangle stripper etc.

From: Udo Giacomozzi
Subject: Re[2]: [Gnash-dev] Questions about trapezoids, triangle stripper etc.
Date: Mon, 2 Oct 2006 09:53:08 +0200

Hello Rob,

Saturday, September 30, 2006, 5:05:58 PM, you wrote:
RS>   Very cool! Looks like you've made good progress. Do any of your other
RS> renderer changes effect the OpenGL backend ?

Yes, indeed. It makes all other renderers unusable for the moment.

RS> Now that this is starting to work, I wonder about getting it all
RS> checked into CVS.

The problem is that massive code changes were necessary. Of course I
kept in mind that other backends should continue to work in the end.
The biggest difference is, that the call of the display() method of
shape_definition is directly passed to the renderer. This was
necessary so that AGG can render all the original edges. The
tesselator/mesh set part is bypassed completely.

The plan is that this is moved to the renderer class, so that the
class is still backward compatible for other renderers. This means
that if you do not overwrite certain methods of the base class (like
the AGG renderer does) it goes the old way through the tesselator /
mesh set processor and generates a bunch of triangles that the other
renderers can work with.

With other words, existing backends will continue to work without any

You see there is much work involved and there are some open questions
(which will get answered as soon as I "need" them):
- how caching will be implemented
- I'd like to rewrite the font part, too (let the renderer decide if
  and how it really wants to use bitmap caches)
- there is some discussion going on about bitmap loading
- still have to see if my current implemention fits the Gnash data
  model well (since this is a major change in the source code, I'd
  like to do it well)

In the meantime, the current AGG backend could be added to the CVS by
using some #ifdefs, but this seems like an odd solution to me...

After all, I expect a few changes in common parts of the Gnash source
code that will break existing backends (for the moment)...


reply via email to

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