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

[strk]

On Tue, Sep 19, 2006 at 01:22:15AM +0200, Udo Giacomozzi wrote:

> Yes, I digged (still do that) step by step through the code and write
> down what I learn from it. I already wrote lots of stuff because I try
> to be very detailed. Once done I'll post it here so you guys can
> review it in case some parts are wrong.

A convenient way to write notes while stepping trough the code is
by using Doxygen comments (basically use three slashes /// on comment
right before functions, methods and classes declarations). That way
a 'make apidoc' run under doc/ should bring dox out in HTML format
(including class diagrams)

> The most difficult thing is that the code is sparse across lots of
> files and even more classes. Sometimes it's hard to follow the logic
> of the implementation..

I can feel your pain, most cleanups are toward making this simpler.

> Well, I did concentrate on the parsing and rendering code, but not yet
> on the playing code. However, I'm quite sure it is done at play time
> since it has to deal with transformations, morphing and such. For
> example, curves (splines) are converted to lines (a "mesh") starting
> in the display() method of the shape.

Eh. For example, I don't like definitions to expose a 'display' method.
It should be the renderer having a display() method instead.

> Of course these lines are an
> approximation of the original curve and the number of lines used to
> reconstruct the curve depends on some factors, like the current size
> of the curve. For example when you zoom a sprite (MovieClip) it will
> re-calculate the lines to stay below a certain error tolerance.

I think all the intermediate representation only needed for rendering
should happen and be cached inside rendering classes, not character
definition.

> I've found no code for dynamic drawing. However,
> server/parser/shape_character_def.cpp would be the place to look since
> it is the starting point for everything that's visible. In theory one
> can change the "path", "fill_style" and "line_style" properties of a
> "shape_character_def" at any time as long as it's cache
> (m_cached_meshes) is cleared. The mesh will be re-generated next time
> display() is called.

Ok, so you suggest that ActionScript code actually creates "definitions"
rather then "instances" ?

> There may be problems with shapes, however, since the code (especially
> the "tesselator") makes some assumptions on the on the way shapes are
> defined. AFAIK, shape holes are a problem for the tesselator, but the
> Flash IDE already solves them at design time (but I'm not very sure on
> this). The AGG renderer probably would have no problems with this, but
> I can't tell about the Gnash tesselator. I believe it just would look
> wrong at worst.

Ok, so it does some sort of "optimization" for the SWF-defined shape,
correct ? Maybe we won't have problems with this as the Drawing API
is very similar to the tags that define a shape (lineTo, moveTo, etc..)

> I'd say it will be difficult to really separate the parsing part from
> the playing part because that would mean lots of rewriting. The code
> seems very weaved, probably to gain some speed optimizations. For
> example, the character shape does everything from reading,
> transformation, caching and rendering. However, it does nothing at a
> low level. Reading is done by external functions that create a bunch
> of classes. Starting from an "edge" the shape is transformed using a
> few intermediary classes until everything is simplified to a list of
> triangles. To accomplish that lots of other classes here and there,
> like the tesselator, are used. In a certain way it actually makes
> sense, because the shape_character_def is completely responsible for
> it's shape and is probably the best way to control the cache.
> 
> Ok, you could extract the parsing part and simply pass the curves to
> the class, however I currently see no real benefit from that. If the
> only point is to support dynamic drawing it is possible to add a
> simpler constructor that does not use any parser and can be used to
> add curves later.

mm.. Note also that the Drawing API is a set of methods of the MovieClip
object (basically, sprites). So, we should be able to *add* lines and fills
to existing set of shapes (grouped into sprites). There's no concept of
*multiple* shape in ActionScript, it's like each MovieClip has an associated
*single* shape initially blank on which you can draw.

> Coming back to the renderer, I start to doubt it's really necessary to
> rewrite the renderer class. Simply everything is decomposed to
> straight lines (polygons and outlines). Looking at the mesh set cache
> (see above) I'd say it's probably better than passing the original
> curve to the renderer who would probably try to render it too
> accurately and would have to recalculate it again and again.

What about moving the decomposision and caching inside the renderer ?

> Instead, I'm thinking of allowing the renderer to activate some bypass
> mechanism that tells the shape class "hey, I have my own tesselator -
> you don't need to do it". That could be probably be extended to even
> bypass the cuves-to-line transformation, if the renderer really can do
> that better anyway.
> Anyway, the mesh cache should remain in the shape class since it
> depends too much on it.

Again, what about moving mesh computation inside the renderer ?
We might port the existing code into a specialized class which could
be used as it is or derived from by rendering classes.
The class would provide decomposition, meshing and cache.

> I have a completely different question: Maybe I'm stir up a hornets'
> nest but could you explain a bit the story of Gnash? I know that it
> has it's origins in GameSWF and AFAIK the project is split because the
> original author didn't want to include some of your patches. I'm
> asking because I'd like to know how the single parts of Gnash evolved
> technically. For example, it seems that no one here apparently knows
> anything about the rendering part and most development is focused on
> other parts of the project. Perhaps it helps me to understand the
> interaction of the code when I know which parts have been developed
> "independently". I hope you understand what I mean...

Most of the work has been (is being) refactoring of existing code into
a more modular and better designed architecture. I think no one did touch
the rendering part yet. The Gui part has been redesigned, the action
handling code refactored and ActionScript classes drafted (work in progress).

Well, I think you can really feel free to redesign the whole rendering
part if you think you know what you're doing :)

--strk;