I've been hacking on hardware video decoding support in an experimental branch ('hwaccel'), and just added support for Gnash to load the renderer at runtime. So that means one can change between Cairo,. OpenGL, and AGG when gnash is started. It's also configurable by a gnashrc setting. Currently I'm just putting all the backends in one big library, and also all the GUI glue code. Luckily there were zero name collisions on anything.
The original idea was to make them dynamically loadable plugins, but for now the big render library works. (in the branch, that is). I'm also considering renaming backend to librender, and in the branch, also moving libvaapi under librender. If anyone decides to play with this, run 'gnash --render-mode (opengl|cairo|agg)'. The new option for HW video accelerators is '--hwaccel (none, vaapi, xv)'. So far I've tested this on an Nvidia (binary blob and libvdpau required), and Intel (965 required), and supposedly ATI works with libxvba. The last thing I need to fix before migrating this to trunk is currently if vaapi is enabled, but you don't have supported hardware, it doesn't handle this gracefully at all. (it segfaults, actually) it should also be possible to find the best defaults for a platform, for example testing for opengl/vaapi support, then dropping back to agg/vaapi, then agg/xv, then agg/none. Unfortunately Gnash's Xv support has a major scaling bug... So far I actually haven't seen much performance improvement in my testing, (mpeg4 n an FLV) but it looks like the bottleneck is in our renderers. - rob - _______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev