2D games and glCopyTexSubImage2D()

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?

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)

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