Re: [Gnash-dev] embedded graphics & Gnash

[Bernd Kischnick]

Hello,

Am 24.06.2010 um 10:21 schrieb Gwenole Beauchesne:

> However, I still think Cairo could serve a better purpose because  
> there are both OpenVG and OpenGL backends and the newer OpenGL  
> backend is promising. i.e. we can have HW accelerated rendering on  
> Cairo supported platforms, which is plenty nowadays. Would it be  
> possible to evaluate the performance of the current Cairo -> OpenVG  
> path vs. this dedicated OpenGL ES path on your OMAP board?

in my project, we also evaluated the swfdec-player, which has a cairo- 
backend.

We tried:
  swfdec
 8    cairo with software-fallback renderer
      cairo with OpenVG-backend
 6        OpenVG software renderer (AmanithVG)
 5        OpenVG->OpenGL-ES translator (AmanithVG)
 -        OpenVG libraries as provided by the hardware manufacturer  
don't work (Freescale MPC5121e)
gnash
10    AGG renderer
<1    existing OpenGL-renderer marginally patched for OpenGL-ES 1.1
30    heavily optimised OpenGL-ES 1.1 renderer (see one of my last  
mails)
        (30 seems to be a hardware limitation; it doesn't get much  
faster than this even for movies more simple)

The numbers are frames/second with a perfomance test swf similar to  
our GUI.

As you can see, the performance was quite disappointing for the OpenVG- 
backends.
(Especially in the case of the vendor libraries, of course, but it's  
quite safe to assume that the performance would be very similar to the  
OpenVG-OpenGL-ES translator).

Whereas a software-renderer like gnash's AGG backend does profit from  
redraw-region clipping to minimise the graphics work to be done in  
each frame, the OpenGL- or OpenVG-based solutions are able to leverage  
the hardware acceleration, but have to redraw the screen completely  
with each frame, even if there are no graphical changes. Embedded  
platforms tend to share the system memory with the framebuffer and  
graphics accellerator buffer, and in this case the RAM bandwidth  
burden alone is not negligible.

In our case, the GUI we had to support unfortunately must cope with  
changing objects in opposite corners of the screen, and the existing  
redraw region strategies in this case result in the complete screen  
being repainted anyway.

So we learned that you have to optimise your code a lot, even if  
you've got hardware-acceleration.
We would probably have been able to get similar performance with a  
software renderer and a sophisticated redraw-region algorithm, e.g.  
based on quad-trees. But that's not the way we chose.

- Bernd