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

[Udo Giacomozzi]

Hello strk,

Friday, February 16, 2007, 6:52:48 PM, you wrote:
s> The advantage of storing pointers, for example, is that we
s> can reuse line/fill style definitions even between characters
s> definition. Example:

Ok, I understand what you mean, however I fear changing this design
will make it more complex, which is not often a good idea. And, "if it
ain't broken, don't fix it" ;)

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

Reasons against:

- memory savings not relevant, if any

- makes it more difficult for the renderer, which has to deal with
  fill/line indexes anyway and would have to rebuild these indexes on
  the fly

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

Ok, we could discuss now if the ActionScript drawing API defines a
character definition or an instance... ;)
Anyway, a character defined at runtime will *never* have a second
instance. I suggest thinking of the runtime-defined character like a
special sprite-child of a sprite.

ActionScript code generates a character definition (an instance can
only transform a character!) so if you start putting
definitions/paths/styles into the instance you will have *lots* of
work adjusting render_handler_tri and rendler_handler_agg.


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

You'll have to implement the detection of duplicate fill/line styles
anyway, so why not implement it just for the drawing API? I suggest
all drawing calls to modify shape_character_def directly and leave
styles there too (**much** easier).

Note there is no way to *modify* the drawings made with the drawing
API, you can just clear() everything and start from scratch.

In your example this would still lead to just two line styles. Would
be interesting to know how Flash itself deals with this.


>> 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.

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

Unless you really find and share matching styles there is no better
place for it, simply because the Flash data model works like this :)

Udo