On Mon, Sep 25, 2006 at 06:23:32PM +0200, Udo Giacomozzi wrote: > I skip the cache part until basic rendering works. However, how do you > suggest the cache to be stored? It really seems to be the best if it > is stored in the *definition* of the character, but which would be a > clean way to store cache objects? I'd like to let the renderer decide > how the cache should look like. But I don't like to put a simple void > pointer there...
I faced the same problem with bitmap_info. Basically, bitmap_info are associated with bitmap_character_def, which is read at parse time. The problem is that bitmap_info are created trough a call to the renderer, so, like meshsets, should be seen as renderer cache instead. I think that leaving the bitmap_character_def ignorant about the cache is a good thing, and we could pass bitmap_character_def references whenever needed (in fill styles for example, but also when calling the renderer to draw them). In turn, the renderer, whenever gets to a bitmap_character_def to be drawn, shoudl chekc wheter a cache item is already associated with it, and if not create one and associate it. I guess the same applied to mesh sets and friends. About the void ptr, a possible implmentation might be defining an abstract class called RendererCache and store a pointer to it in the definition classes that allow some form of caching (like bitmap_character_Def or shape or whatever). The renderer would then define a subclass for it and dynamic_cast back when getting the cache value. What do you think ? --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
