The new GL_EXT_framebuffer_extension is essentially a platform-independent
replacement for pbuffer and render-to-texture functionality. It allows
for true render-to-texture functionality without the large VRAM footprint
requirements of pbuffers. For example, one can create a framebuffer object
(FBO) with only a 32-bit color buffer and attach a stencil buffer only when
it is needed. So for apps that don't make use of complex clipping, we could
probably avoid creating a stencil buffer, which would cut down on VRAM usage.
Currently, we would need to create a pbuffer to get the same functionality,
but typically the windowing system will allocate buffers that Java 2D doesn't
need, such as a backbuffer, depth buffer, accum buffers, and so on.
(Pbuffers can sometimes require as much as 192 bits per pixel, so the savings
with FBOs are obvious.)

Even better, one can render to an FBO without switching contexts (calling
MakeCurrent() over and over can be costly). Currently, context switching
overhead makes Swing rendering slower when OGL is enabled. This is because
Swing will render a couple things into their backbuffer (a pbuffer), copy
the pbuffer to the screen, and repeat. Each time we switch the context
from the pbuffer to the screen and back to the pbuffer, we incur significant
overhead. This overhead can be avoided (or at least minimized) when using
the FBO extension.
###@###.### 2005-04-14 19:32:11 GMT