[Gnash-dev] Re: subshapes

[Udo Giacomozzi]

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