In 1.5, new API was added to allow for the creation of non-opaque
VolatileImages:
   GraphicsConfiguration.createVolatileImage(int w, int h, int trans);

The OpenGL-based Java 2D pipeline currently returns a system memory based
VolatileImage from this method (if the trans parameter is not OPAQUE).  In
theory, we could create a pbuffer in this case, if the GraphicsConfig supports
a stored alpha channel.  That would allow for hardware accelerated rendering
to a translucent offscreen surface, and copies from that surface would also
be accelerated.

A number of developers, especially on javagaming.org, are looking forward to
using translucent VolatileImages, so we should do what we can to support this
feature in hardware.

If you are making limited updates to the VolatileImage (e.g. in a sprite
situation, where the contents of the sprite are not changed after the initial
update), it may be better to use a "managed image" instead:
    GraphicsConfiguration.createCompatibleImage(int w, int h, int trans);

The benefit of managed images is that they are cached in texture memory (in
the OGL case), even for translucent images, so performance when copying from
that managed image will actually be much better than a translucent pbuffer. 
  xxxxx@xxxxx   2004-02-24

If the GLXFBConfig associated with the given GraphicsConfig supports a
stored alpha channel, we can simply create a new pbuffer as the main
volatile surface.  Note however, that there are a couple places in the OGL
pipeline where we assume that pbuffers are always opaque, so we would need to
adjust those cases accordingly.
  xxxxx@xxxxx   2004-02-24
Now that support for the FBO extension has been integrated (see 6255507), this
RFE is much more interesting.  The FBO extension allows you to create an RGBA
texture and bind it to an FBO, and this typically works fine even if the
underlying GLXFBConfig or PixelFormat does not have a stored alpha channel.
So this will be the preferred way for us to offer translucent VolatileImage
support: if the FBO extension is available (and FBO support has been enabled
via the sun.java2d.opengl.fbobject system property) then we will attempt to
create a translucent FBO.  If for some reason this fails, we will fallback on
the existing code path, which will create the surface in system memory.

If the FBO extension is not available, but the GraphicsConfig supports a
stored alpha channel, then we can still try to create a pbuffer, and it will
have an alpha channel, which effectively makes it a translucent surface.  This
situation is not terribly common since it is unlikely that we will choose a
GLXFBConfig or PixelFormat that supports stored alpha.  But on Unix at least,
the user could potentially choose a GraphicsConfig that does support stored
alpha, just in case they are desperate for this feature.

I've tested this with FireStarter, and it's nice to see that with
sun.java2d.opengl.fbobject=true, we can get translucent VolatileImages
transforming and blending just as fast as managed images.  Pbuffer-based
translucent VolatileImages aren't blitted nearly as fast as FBO-based ones
(due to the extra context switching required for pbuffer blits, and due to
the fact that pbuffer blits can go through a much slower path in the drivers
when blending is enabled), but at least rendering into the image will be
hardware accelerated, which is good enough for many people who have requested
this feature.
Posted Date : 2005-09-01 21:32:38.0