gnash-dev
[Top][All Lists]
Advanced

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

[Gnash-dev] OpenGL Rendering


From: Quinn Storm
Subject: [Gnash-dev] OpenGL Rendering
Date: Mon, 11 Jun 2007 10:13:00 -0400
User-agent: KMail/1.9.6

I've recently thought of another possible method to reduce our OpenGL woes, 
however it would be an Xorg-only method (though for most of our OpenGL 
targets I think that's ok).  Basically, my thinking is:

* our biggest two problems with OpenGL are anti-aliasing and automated testing
        * automated testing can be done with osmesa or with an X server present 
& the 
proposed method
        * anti-aliasing is slow on many common platforms because of lack of 
certain 
support

An answer to all of this, I think, is the GLX_ext_texture_from_pixmap 
extension, supported by most Free drivers and by the NVidia proprietary 
driver.  Here's the rendering path I am proposing:

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

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

This also gives us the offscreen buffer (w/ hardware acceleration, and exactly 
the same as would be rendered to screen) but does require an X server 
present.  This does though give us the ability to do automated testing as the 
calls necessary are easy to implement.

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

If this proposal makes sense to the interested parties, I think I could 
implement it fairly quickly, but I don't want to waste anyone's time until I 
know that we're willing to add these [minor] requirements.

--Quinn




reply via email to

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