Hello Bastiaan, Tuesday, October 2, 2007, 5:42:25 PM, you wrote: BJ> I'm reimplementing the OpenGL renderer after having condemned the current BJ> version. While doing this I've come across a concept known as subshapes, BJ> about which I'm still a little hazy.
Hmmm. I was pretty sure I documented sub-shapes somewhere, but can't find it... :( BJ> The purpose of subshapes I don't completely understand. Although I BJ> understand that Flash wants to combine shapes into a single character, BJ> looking at lumi.swf I see many distinguishable shapes but not a BJ> single path with member m_new_subshape set. So I'm left to conclude that BJ> subshapes are either not indicative of a distinguishable shape, or the BJ> implementation in Flash movies is not very consistent. Better you look at subshapes.swf (in testsuite). It is a very simple example for a shape with sub-shapes. As you can see, the red line is *between* the two filled rectangles. If you would ignore the m_new_shape flag (it's not "m_new_subshape") then you would normally draw the two rectangles and on top of it the line. Think that any shape can have itself many layers. When walking through the paths of a shape the m_new_shape flag tells you that "this and the following paths belong to the above layer". You need to draw a outline before a rectangle if the rectangle belongs to a higher layer. AGG simply counts the number of subshapes a shape has and then goes into a FOR loop rendering fills and outlines of one subshape layer at a time. See draw_outlines_impl() which has a "subshape_id" argument. It will only process fills and outlines matching that subshape level. BJ> I also note that if you were to render all shapes in the same order BJ> they occor in the character, the subshape automatically has the correct BJ> level. (At least in my testing of subshapes.swf.) Can't agree with this. All shapes have a list of paths. The path defines the outline of both fills and strokes. A path does not have to be closed, ie. a path with just one line is a fully valid path. Only if you put *all* paths [of a subshape] together, you have enough data to render the [sub-]shape. However, nothing except the m_new_shape flag tells you anything about the drawing order. Probably subshapes.swf contains three paths: one for each rectangle and one for the line. Since this is a simple example all single paths are closed and and can be drawn individually. I'm pretty sure the second (middle) path is the one of the line. So yes, you could draw them in the order they appear in the definition. But when drawing a complex shape you can't render each path individually. For a more detailed description of the rendering mechanism see \page render_handler_intro in render_handler.h Have a look at the attached SWF file. I haven't tested this but the bottom two rectangles (the blue ones) should be made up of two paths that only make sense when they are combined (like one path for the common outline and another one to divide them). 111111111111111111211111111111111111111 1 2 1 1 2 1 1 2 1 1 2 1 1 2 1 1 2 1 111111111111111111211111111111111111111 Do you understand now? Udo
subshape-ex.swf
Description: application/shockwave-flash
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
