[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnash-dev] PATCH: gnash 0.8.5: OpenGL-ES 1.1 renderer and framebuffer-b
[Gnash-dev] PATCH: gnash 0.8.5: OpenGL-ES 1.1 renderer and framebuffer-based player
Fri, 18 Jun 2010 12:11:54 +0200
Hi all, hello Rob,
here is a huge patch based on gnash 0.8.5 to get a standalone player
with a renderer using OpenGL-ES 1.1.
This work is far from finished and not suitable yet to include it in
the general gnash source tree.
It's sufficient for my work in a project where gnash is used to run a
GUI of an embedded device, playing a limited and tailor-made set of
known SWF files.
This port is only tested on the MPC5121e SOC made by Freescale, which
provides a PowerVR MBXlite graphics engine that supports OpenGL-
Embedded Subset 1.1.
It's probably possible to run it on the ADS prototyping board, using
the DVI or VGA output.
- the glues-library, version 1.4, available at http://code.google.com/p/glues/
- the OpenGL-ES driver for the hardware, provided by Freescale with
Application Note AN3793
(Note: there are two different versions of the driver, "build 9"
and "build 13". "build 13" doesn't seem to provide pbuffer surfaces.)
- the linux kernel driver for the MBXlite, contained in Freescale's
board support package mpc5121ads-20090603_ltib
other known limitations:
- video output is not supported
- drawLine() and drawPoly() are not implemented
- mask shapes have never been tested
- glyphs are always drawn last
(to avoid colour-bleed-through artifacts from their anti-aliased
- SWF graphics are not antialiased (glyphs are)
During development, we also supported the combination aqua-gnash-
Player with the OpenGL-ES-renderer running on MacOS X.
This combination is included in the patch and might still be functional.
When we started, we thought that we only need small changes to the
existing OpenGL renderer.
But we ended with a nearly complete rewrite, so it would have been
better to create a separate opengl-es renderer instead of heavily
patching the existing one.
Some strategies used in the existing OpenGL renderer turned out to be
unsuitable for an embedded device.
First, the existing OpenGL renderer used the accumulation buffer for
general antialiasing of all drawing operations.
The vertices to draw were collected in OpenGL display lists, which
then were drawn 8 times with slight sub-pixel position jitter to get
an antialiasing effect.
OpenGL-ES 1.1 doesn't have display lists and no accumulation buffer.
Repeating all draw operations for anti-aliasing is much too costly on
an embedded device.
Also, the MPC5121e doesn't provide a multisample buffer, which would
be the modern way to get antialiasing.
As a result, we only provide for anti-aliased glyphs.
Second, the glyphs were rendered by tesselating the paths provided by
the front end, and drawing the resulting triangles for each glyph on
This turned out to be completely unworkable for an embedded platform.
Some glyphs resulted in 30000 triangles, used to draw a glyph which
had only maybe 10 white pixels on the screen. The huge number was
partly caused by a bug in the path interpolation algorithm, but even
without the bug, hundreds of triangles could be used for a single glyph.
Therefore, we implemented a bitmap texture renderer for glyphs, and
cache all rendered textures. In this way, two triangles (four
vertices) per glyph are sufficient for the actual OpenGL drawing
Third, the existing renderer had to re-do all its work in each frame.
We are now caching practically every calculation we do, and it pays off.
Typically, most of the screen contents stays equal between successive
With our test SWFs used for performance evaluation, the OpenGL-ES
renderer ran about 100 times faster than the OpenGL renderer.
I hope you have some fun with the renderer,
- Bernd Kischnick
Description: Binary data
|[Prev in Thread]
||[Next in Thread]|
- [Gnash-dev] PATCH: gnash 0.8.5: OpenGL-ES 1.1 renderer and framebuffer-based player,
Bernd Kischnick <=