[Gnash-dev] embedded graphics & Gnash

[Rob Savoye]

So I've been playing with that big patch we got the other day that had
support for OpenGL-ES. For most lower end embedded devices, like a
phone, you need hardware acceleration, as software rendering just
doesn't go fast enough. So anyway, here's what I've learned, and how it
effects this patch. I figured I might was well spread this info around.

The patch uses OpenGL-ES 1.1, which also requires a libGLU ported to
GLES 1.1. There are several partial ports of the SGI version to GLES
1.1, but all appear to be unmaintained. libGLU is where all the
tesselation code lives, which is currently needed by this patch. So
using this patch as it is may not be such a good idea unless we want to
maintain our own libGLU package. (which I don't)

OpenGL-ES 2.1 is what the iPhone and Android are now using, although
both have partial GLES1 support. (not enough for this patch though)
Supposedly GLES2 is much faster, etc... GLES1, but it's *very* different
in that you have to write these things called shaders. (which look nasty
complex) And there are no libGLU ports to GLES2, as it's different enough.

So since I was considering all options, I looked into OpenVG a little.
Adobe uses OpenVG for their flash player, so it's not entirely a bad
idea. It's much higher level than GLES1 or GLES2, so maybe less of a
painful learning curve. (I am not a graphic hacker).

Implementation wise, there are multiple implementations of all of these
libraries. One nice thing is that Mesa 7.8.1 also has support for these
all, and maps the calls to EGL (the device level API) and OpenGL. So
it's also possible to run all of these on the desktop. Nice for
debugging. With the newer Gallium based drivers in Mesa (like Nouveau),
you can have a 100% free stack, and still use hardware acceleration.

Most hardware manufacturers have their own proprietary implementations,
but as all of these libraries are based on available specs, they're
source code compatible. I also found multiple open source and public
domain implementations of all of these in varying states.

One nice thing and OpenVG is that we would only need one rendering
backend, as it would use hardware acceleration if it was present, and if
not, drop back to software rendering with similar performance as AGG has.

So anyway, as I'm sure there are people on this list that know way more
about this subject than I do, so I'd love to hear some input on this, as
implementing any of these would be a pile of work...

        - rob -