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; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
