Re: [Gnash-dev] class gnash::path

[strk]

On Fri, Feb 16, 2007 at 03:49:50PM +0100, Udo Giacomozzi wrote:
> Hello strk,
> 
> Wednesday, February 14, 2007, 2:09:56 PM, you wrote:
> s> Also, this makes gnash::path depend on the existance of a
> s> gnash::shape_character_def in order to be useful.
> 
> Well, that makes sense. The path defines only the coordinates of the
> path itself and fill/line styles used for the path. These styles are
> shared between possibly lots of paths.

Sure, I'm not discussing this. The same effect might be obtained
by storing pointers to fill/line styles rather then offset into
a yet-to-be-defined vector.

The advantage of storing pointers, for example, is that we
can reuse line/fill style definitions even between characters
definition. Example:

        Shape1 defines a solid red fill for its shape
        Shape2 defines a solid red fill and a solid blu fill

In this case we could globally have only 2 styles: a solid red and a solid blu.
Instead, we have 2 styles in Shape2 and 1 style in Shape1, with gnash::path
instances pointing to offset in their definition (!).

The other advantage (the main one) is that we do want to use gnash::path from
ActionScript (Drawin API), and having gnash::path tight to shape_character_def
is not apporpiate design-wise, as long as shape_character_def is an *immutable*
definition (by comments on character_def).

Remember that using the Drawing API there's no way to define line/fill  styles
and refer to them by offset/index. Rather you call setLineStyle() or 
beginSolidFill()
whenever you cange your drawing style. Consider drawing a line in alternating 
red
and blu segments: how many styles do we want to define ? And where do we want 
to store
those styles ?

> So, a path depends on a fill style and a line style list and the
> shape_character_def is the instance that brings them together.

So far, shape_character_def only role with reguard to gnash::path is as
an holder for line/fill styles, I'd like to find a substitute for it.

--strk;