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