I've been playing around with some nifty 2D effects lately making heavy use of glCopyTexSubImage2D() to use textures as buffers. On my G5, this runs great to no surprise. Swapping buffers is still by far the most expensive operation with a large window. (the texture size is constant)

However, how will this run on older cards/machines? As this also uses rectangle textures, a radeon will be the lowest targeted card. Also, how will the size of the texture affect speed? About as much as a resolution change or more?

You can render-to-texture via pbuffers or offscreen windows to avoid the copies. Of course, then you pay context switches.

So what exactly are pbuffers? I was under the impression that they were used to render an image into system memory instead of a window. Also, this has to be cross-platform. I'm working on this with some of my linux using friends. (and if one of them has his way, windows too)

pbuffers are for accelerated render-to-texture, not render-to-memory. They're not cross-platform, but the different APIs are similar. SDL might have a cross-platform API on top?

EXT_framebuffer_object will provide cross-platform pbuffers, but it's not yet implemented in any drivers on any platforms AFAIK.

That's right. It is a method to render to a chunk of memory, and then treat that same chunk as a texture, without copying.

Let's see if I can briefly describe the various ways to do render-to-texture, with the advantages (+) and disadvantages (-) of each:

* glCopyTexSubImage2D
+ easy to implement: just render normally, copy to texture, use the texture.
- destroys previous framebuffer content.
- requires copy.

* offscreen window
+ eliminates copy.
- requires an additional context.
- requires 10.2 (or gross hack in 10.1.)
- on certain (nvidia) hardware, only works with rectangle texture target.

* pbuffer
+ eliminates copy.
+ works with any texture target.
- requires additional context in fullscreen (may use single context in window.)
- requires 10.3.
- does not (currently) work with multisampling.
- buggy on certain (ati) hardware.

* framebuffer objects
+ eliminates copy.
+ eliminates need for additional context.
+ works with any texture target.
+ allows attaching to various parts of a framebuffer (front/back/depth/stencil...)
+ beats up pbuffers and takes their lunch money.
- only exists on paper for now.


Cross-platform-wise, only glCopyTexSubImage2D (and framebuffer objects, in some distant galaxy...) is completely portable, because the other methods require interaction with the window server. So that means OS-specific code to create the window/context. But pbuffers are the common way to do render-to-texture on Windows/linux, so it shouldn't be too hard to port.

After testing it on our G4 at home, the animation still seems very smooth, so it might not even be a problem at all as long as we don't use too many render passes.

Having more than one context means you need some code to share textures between them right? Currently I'm prototyping this largely using OSC's RubyGameCommon, which uses glut, but eventually I'm going to rewrite most of my graphics classes into C, and break the dependence on GLUT. So this isn't going to be a problem yet.

Does managing contexts work differently depending on the OS/API?

Context sharing in CGL/AGL/NSGL is set up at context creation time. It is OS and API specific, and I don't think it is possible via GLUT.

However, you don't necessarily have to share contexts. It depends what you're doing.

I was afraid of that. In that case, I'll probably hold off on all this for a while, and just continue using glCopyTexSubImage2D() until it proves to be a problem.

Thank you all, this was very informative as always.