Re: [Gnash-dev] OpenGL Rendering

[Udo Giacomozzi]

Hello Quinn,

Monday, June 11, 2007, 4:13:00 PM, you wrote:
QS> * our biggest two problems with OpenGL are anti-aliasing and
QS> automated testing 

The current OpenGL also lacks some implementation details that are
worse than just bad quality (see Savannah bug list). Most of them
should be easy to fix for someone familiar with OpenGL and our OGL
backend, though...


QS> * render frame to pbuffer (which is an offscreen hardware accelerated buffer
QS> bound to an X Pixmap) at double size.
QS> * use GLX_ext_tfp to bind that pixmap to a texture (this is far faster than
QS> something like glCopyTexImage)
QS> * render that pixmap at 1/2 of its size (normal size) to draw the frame

That certainly would improve rendering quality, but be aware of this:

- maybe consider 4 times supersampling, like PP does

- not everything should be anti-aliased! There are some rules
  regarding "hairlines", which in certain situations should *not* be
  anti-aliased and should be aligned to the real pixel grid. This is
  to avoid blurry hairlines. Maybe you can fix this by aligning
  hairlines and draw in a way (2 resp. 4 pixels thick) so that
  downsampling would lead to a nice line.
  See build_agg_paths_rounded() in AGG renderer for more information.

- PP normally does not anti-alias video and in certain cases bitmaps
  (missing "smooth" setting). If OpenGL ever scales video using
  neares-neighbor method (non-smooth) it probably would look strange
  after downsampling. Not really an issue, I think, but worth to
  mention.


QS> Also, to make this even more well supported are that we could make the 
pixmap
QS> a fixed power-of-two size (and if lets say the hardware didn't support a big
QS> enough pixmap, we could always stitch more than one together, but that's a
QS> bit more work), this way we don't have to worry about NPo2 support.

Dunno what's NPo2 but for a 1100 x 100 movie this would result into a
2048x2048 pixels buffer?


QS> The only major drawback to using/requiring GLX_EXT_tfp is that the ATI
QS> proprietary drivers don't support it, and the method in general slightly
QS> increases our requirements (things like needing a 2k-by-2k texture size), 
but
QS> for desktop / high-end embedded use, I think this works anyway, as anywhere
QS> you have modern OGL you should have these, and we can always fall back on 
our
QS> quite performant AGG renderer in cases where the required support is 
missing.

Please note that a increasing number of embedded "devices" support
OpenGL but I don't know if they have the performance you want. So
please consider fallback for less performant (but present) OpenGL.



Udo