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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
