[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] embedded graphics & Gnash

From: Bernd Kischnick
Subject: Re: [Gnash-dev] embedded graphics & Gnash
Date: Thu, 24 Jun 2010 12:40:05 +0200


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:
 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)
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]