At least in theory, a SWF file can have several shape definition tags. One could consider each of those shapes.

However, Flash combines several distinguishable subshapes (you can also call them shapes if you prefer) in a single shape definition. That means that Flash will offer a new set of fill and line styles and drawing of the new subshape must take place after the previous subshape.

Currently, the Path::m_new_shape member determines whether or not a new subshape should be started by the renderer.

> Currently, path has a member which indicates whether or not
> the current path is the start of a new shape.

Is the flag used for indicating a new sub-shape or a new shape? What is the difference between a sub-shape and a shape in definition?

> This means that
> the renderer should draw all paths previous to the current
> path and the current and following paths should draw over the
> previous paths.

Sounds really inefficient.

> I'm changing this system by changing shape_character_def to
> maintain an array of subshapes instead.

This is what we have at the moment:

std::vector<Path> m_paths;

What is the difference between a subshape and a Path? There seems to be no subshapes defined in Gnash.

> That way, the renderer can just loop over the array when it
> needs to render, making the algorithms more natural.
> Additionally, in the future, we might just invoke the renderer
> once for every subshape, making the renderers even simpler.

Currently, path has a member which indicates whether or not the current path is the start of a new shape. This means that the renderer should draw all paths previous to the current path and the current and following paths should draw over the previous paths.

This is a cumbersome way of separating subshapes. Obviously the renderer needs to be aware of this path flag, making drawing algorithms more complex. In fact, almost every algorithm touching paths becomes more complex.

I'm changing this system by changing shape_character_def to maintain an array of subshapes instead. That way, the renderer can just loop over the array when it needs to render, making the algorithms more natural. Additionally, in the future, we might just invoke the renderer once for every subshape, making the renderers even simpler.