Re: [Gnash-commit] /srv/bzr/gnash/trunk r11247: Make the renderer no longer a singleton. It is now part of the RunResources

[Benjamin Wolsey]

>   
>   It should be relatively easy to select the renderer at runtime now.


I don't plan to work on runtime selection. Anyone who wants to improve
the renderer handling in the GUIs is welcome to and add this feature.

The biggest question for the renderers generally is whether the current
method of converting all images immediately to a BitmapInfo has any
advantage. This is the only purpose of giving the core libs a renderer
during parsing.

For the agg renderer, the GnashImage is simply stored without any
conversion. The other renderers may do something more useful. However,
if they do convert it to another format, it must then be convertible
back to the RGBA-32 format of GnashImage for the BitmapData functions.

The RunResources object requires in any case a renderer instance for
those BitmapData functions. But if we stop using the BitmapInfo system
and instead store bitmaps in the core, it would be possible for the
internal (BitmapData) and external renderers to be different. It might
be necessary to use a different agg renderer anyway because of the pixel
format required for BitmapData (I'm not quite clear about this), but
even using agg internally and cairo externally may be possible (no idea
why that might be useful).

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil