Hello strk, Wednesday, September 27, 2006, 2:18:45 PM, you wrote: s> I faced the same problem with bitmap_info. s> Basically, bitmap_info are associated with bitmap_character_def, which s> is read at parse time.
Agree. Managing raw bitmap data in memory should be up to the renderer (I had not looked at bitmap_info yet, though). However, I'm running into problems with our current idea of moving the display() part into the renderer. When I just pass the generic_character instance to the renderer I also get a meaningless abstract character definition. I would need to check the runtime class instance and typecast it to get access to the shape properties - doesn't look nice to me... Instead, I suggest implementing methods like display_shape(), display_bitmap() and so on (is there much left?) in the renderer. These methods expect the instance and the definition as arguments and do the actual drawing. At least display_shape() could be implemented in the base class and use the current tesselator. One can overwrite it in the correct renderer class to use other tesselators. The renderer can store any cache object he likes in the definition (or maybe also in the instance, if that makes sense) since it has access to it. What do you think? s> About the void ptr, a possible implmentation might be defining an abstract s> class called RendererCache and store a pointer to it in the definition s> classes that allow some form of caching (like bitmap_character_Def or s> shape or whatever). The renderer would then define a subclass for it s> and dynamic_cast back when getting the cache value. Agree. Udo _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
