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

[strk]

On Sat, Feb 17, 2007 at 10:42:09AM +0100, Udo Giacomozzi wrote:
> 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" ;)

I understand your point. Yes, it would be nice to require no changes
in the renderer. Still, we can't say "it ain't broken" as we don't 
curently support the "Drawing API", so it *is* broken.
My feeling is that not redesigning now might be just a procrastination
of the problem, and redesigning later could be more pain :)

> 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

Granted. I won't push on this :)

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

Why does the renderer need to deal with indexes ? Can't it extract
style info from the gnash::path instance directly ?
Like:
        const fill_style& gnash::path::getLeftFill();
        const fill_style& gnash::path::getRightFill();
        const line_style& gnash::path::getLineStyle();

Current "default" styles (index==0) would be returned as
a reference to a static default style.

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

Right. This is the main issue we're discussing.

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

I agree. Every sprite_instance should have an additional entry in the 
DisplayList,
or somewhere else. I think this entry would always be on top of the others, 
right ?
Should MovieClip.clear() also clear the DisplayList or just this "drawable" ?
Also, I think I've read somewhere on the web that new players define something
like a "drawing layer" or similar, which seems to resemble this canvas on which
the Drawing API operates. Does anyone know more about it?

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

This clashes with the "immutable definition" descriptio of character_def.
I think the main problem here is that the renderers are deaing with 
"definitions"
rather then with "instances". BTW, it seems that the ::display method of
definitions get an instance pointer for transformation; this is a mess!
I think renderers should only deal with instances, and instances could
act as proxies to definitions if they don't need additional stuff done
(like in the Drawing API case).

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

We can do this. And yes, it would be easier as won't require changing
anything in the renderer. Still, I find it counter-intuitive. 
I'd prefer abstracting the definitions so that renderer just use
the instance to fetch paths, and paths to fetch fill_style.
This can still work with current underlying storage (everything
into a shape_character_def) but allow for future changes.

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

Adding lines or "clearing" is still modifying it.
Consider invalidated bounds computation...

> >> 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 :)

I think it *is* the correct place for SWF-defined styles, but not for
ActionScript defined ones. Accessing them trought its user (gnash::path)
would allow abstracting this so that the renderer doesn't ned to know.

I'm not convinced myself about redesignign now, but I think abstracting
things a bit would help in the future.

--strk;