Hello strk, Wednesday, September 20, 2006, 3:24:40 PM, you wrote: s> Ok, I see what you mean about not moving the display() part s> in the renderer, still we can move it into instances, rather s> then definitions. What you call a MovieClip is a sprite_instance, which s> derive from character. The definition is a sprite_definition, which s> (should) derive from character_def.
Agree. Oddly the display() method of shape_character_def asks the instance for the transformation matrix. The instance pointer is passed as a parameter to the display method. Quite strange... s> I'd drop the display() method from character_def and leave it in s> character. Agree (provided that these is a _interface for each _def). [Cache] s> It could be a map (possibly hashed) based on character pointer. s> The advantage would be more control on the cache. For example, s> a cache entry could have a time to live, or could have a size limit s> (to reduce memory usage). Not sure about how much would this impact s> performance though. Agree. It would have some advantages because it allows the renderer what things to place in the cache. Don't know this yet, but maybe I can cache the result of the AGG's own tesselator (of course having a completely different type), which could improve performance. However it's important that the cache items are accessed very, very quickly. What would you say if we reserve a "cache" field in the character instance that is completely under control of the renderer? After all it needs to know (because of the cache) which character it currently renders and there would be no faster thing. At the other hand this leads to a distributed cache and the renderer cannot walk over the complete cache to prune unused entries. But he could do that while rendering........ ? Are there any C++ tricks that could be helpful? >> >> server/parser/shape_character_def.cpp would be the place to look since >> s> Ok, so you suggest that ActionScript code actually creates "definitions" >> s> rather then "instances" ? >> >> Uhm, are there character instances? I just know about MovieClip >> definitions/instances.. s> It seems that this was at least an original developer idea at a given s> time. I confirm the code seems not to reflect this all over the places. s> I guess the main use for it is caching definitions (immutable structures) s> to files You mean, when the same, untransformed sprite is used multiple times in a scene? Or for example font letters? Ok, that could really be an issue. However, when the cache is controlled by the renderer, the problem would go away. When the cache is distributed (like above) then it would be probably best to place the cache items in the *definition*. Let's say we have three sprites of the same kind on the stage. The first *instance* calls the renderer class so that it's "path" is drawn. The renderer does so and creates a mesh set, places that set along with transformation information in the *definition*. Now the second *instance* does the same but the renderer notices that it has already done most of the job for that combination of character definition and transformation. So it skips the tesselator part and immediately draws the rectangles. Same for instance #3. The renderer could even take advantage of bitmap caches (potentially extreme performance boost). See this demo at http://antigrain.com/stuff/particle_demo2.exe (apparently only a Windows version available). You see the difference when *activating* the bitmap cache... s> (did you note the .gsc failures?). Uhm. What's that? s> (removed the part about drawing api,don't really know how to proceed s> there, we'd need some intersection detection functions to reorder s> the lines probably). Well, I'd say it's (it will be) up to the renderer to do that correctly. Anyway, I don't think it's something to bother about now since it is completely unrelated to the way the drawing API is implemented. Udo _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
