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

[Udo Giacomozzi]

Hello strk,

Sunday, February 18, 2007, 1:36:06 PM, you wrote:
>> - 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> Why does the renderer need to deal with indexes ? Can't it extract
s> style info from the gnash::path instance directly ?
s> Like:
s>         const fill_style& gnash::path::getLeftFill();
s>         const fill_style& gnash::path::getRightFill();
s>         const line_style& gnash::path::getLineStyle();

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

Because Flash was designed for best rendering performance. It does not
just store vector data - it generates a SWF file that best suits the
renderer, which is a "layered compound rasterizer". It is able to
render a shape with any number of line and fill styles in just one
pass, which makes it very fast. This left/right fill style thing was
made specifically for the way the renderer generates a scan line.

Or, if you want a simple answer: AGG has this kind of rasterizer
built-in and it also works with indexes, not with pointers. Look for
the rasc.styles() call.


>> Ok, we could discuss now if the ActionScript drawing API defines a
>> character definition or an instance... ;)

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

s> I agree. Every sprite_instance should have an additional entry in the 
DisplayList,
s> or somewhere else.

s> I think this entry would always be on top of the others, right ?

No, below all normal Flash objects (of that sprite).


s> Should MovieClip.clear() also clear the DisplayList or just this "drawable" ?

Just the drawable.

Say you have a normal MC named "mysprite" which contains the AS
drawing code. Internally mysprite would have a fixed child named
"_canvas" - not visible for the AS code.
When "mysprite" calls clear() this should clear the DisplayList of
"_canvas", nothing else.


s> Also, I think I've read somewhere on the web that new players define 
something
s> like a "drawing layer" or similar, which seems to resemble this canvas on 
which
s> the Drawing API operates. Does anyone know more about it?

Hmm, this is new to me. Can be.


s> This clashes with the "immutable definition" descriptio of character_def.
s> I think the main problem here is that the renderers are deaing with 
"definitions"
s> rather then with "instances".

Ok, what about making and describing an exception for the drawing API?

Both ways are partly correct, or partly wrong, depending on how you
put it. So it's like choosing the less problematic way.


s> BTW, it seems that the ::display method of
s> definitions get an instance pointer for transformation; this is a mess!

Agree. This was inherited from the original renderer design. Anyway,
render_handler does not much with the instance. It collects the
information required and calls another version of draw_shape_character
which does not need to know about the instance.


s> I think renderers should only deal with instances, and instances could
s> act as proxies to definitions if they don't need additional stuff done
s> (like in the Drawing API case).

Don't agree here. This again would need a huge redesign of the
renderers. Especially render_handler_tri and descendants are deeply
interweaved (triangles mesh sets living in the definition!) which
comes from the original GameSWF design I think. This may be worth to
change, but I personally don't feel like doing it because so much
redesign is involved and could break too much.

Back to the original topic: I don't understand why the renderer should
not work with character *definitions* (except for the drawing API). It
does not harm nor modify them. They contain lots of information the
renderer needs. And, the current design is prepared for some kind of
caching which only works when the renderer knows about the character's
definition. So, why make things more complicated?


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

s> We can do this. And yes, it would be easier as won't require changing
s> anything in the renderer. Still, I find it counter-intuitive. 
s> I'd prefer abstracting the definitions so that renderer just use
s> the instance to fetch paths, and paths to fetch fill_style.

This is a graphics application, not a database :) Some decisions have
to be made in favour of renderer performance / simplicity. We made the
same decision when the renderers began to receive the character
definition as parameter instead of the triangle-mesh-set. There would
be no AGG renderer if we didn't do so.


s> This can still work with current underlying storage (everything
s> into a shape_character_def) but allow for future changes.

What kind of changes do you mean?


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

s> Adding lines or "clearing" is still modifying it.

Yes, of course, I just meant that you can't remove a single line, you
have to remove everything at once.


s> Consider invalidated bounds computation...

No problem, as the drawing API calls are invoked in the instance which
can trigger set_invalidated().


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

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

But the renderer needs to know because he works like that. :)


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

I've made the experience that abstracting too much can lead into
problems. In this very special case I really, really, really suggest
to not to go in this direction. Bold. Underlined. And emphasised. ;)

Seriously, it's not only about avoiding too much redesing work - I
really think that the character definition is the right destination
for the drawing API.


Udo