[Top][All Lists]

[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

From: Bernd Kischnick
Subject: [Gnash-dev] PATCH: gnash 0.8.5: OpenGL-ES 1.1 renderer and framebuffer-based player
Date: 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.

Additional dependencies:
- the glues-library, version 1.4, available at
- 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 textures)
- 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 the screen.

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 operation.

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 frames. 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

Attachment: gnash-0.8.5-opengles.patch
Description: Binary data

reply via email to

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