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  customer 
(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.
  xxxxx@xxxxx   2005-04-14 19:32:11 GMT

N/A

Beta drivers that include support for the FBO extension are just now becoming
available (e.g. the 7590 beta drivers for Linux from Nvidia support it).
Nvidia claims that context switching performance is improved by 2x with FBO.
An initial experiment on my Nvidia GF FX 5600 shows a 14% improvement in
SwingMark scores when using FBOs instead of pbuffers.
  xxxxx@xxxxx   2005-04-14 19:32:11 GMT
FBO support is now in mainstream drivers from both Nvidia (as of 76.64 on
Linux and Solaris, 77.77 on Windows) and ATI (as of 5.7 on Windows).  We will
now use FBOs instead of pbuffers as the accelerated surface for VolatileImages,
but only if the following conditions are met:
  - the GL_EXT_framebuffer_object extension is present (obviously)
  - the new sun.java2d.opengl.fbobject system property is set to "true" (off
    by default)
  - we are able to create an FBO with the appropriate attachments

The reason this will be disabled by default (at least for the near future) is
that there are still some kinks in the drivers.  For example, both Nvidia and
ATI do not yet support stencil attachments for FBOs, which is why I've filed
6313838 (and plan to fix it very soon), so that we eliminate our dependency on
stencil buffers.  Also, on Nvidia drivers, copyArea() is very slow for FBO
destinations (very similar to the bug reported in 6298243), which results in
slow scrolling when FBO support is enabled.  It looks like Nvidia will be
addressing that issue in an upcoming driver release.  Once the above issues
are resolved, we can consider turning on FBO support by default.
Posted Date : 2005-08-22 20:41:16.0

I know this feature is planned for dolphin but it would be a great enhancement for mustang, since it makes the OGL pipeline more useful for Swing rendering.
Big Swing apps are still a bit problatic on platforms where no highly accerlated pipelines are available (Linux, Solaris) so I still see OGL for a way out of X11 if no network transparency is needed.

Anyway, would be really great to see this enhancement soon!

lg Clemens