JDK-5002129 : OGL: translucent VolatileImages should be hardware accelerated
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-02-24
  • Updated: 2005-09-19
  • Resolved: 2005-09-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b53Fixed
Related Reports
Relates :  
JDK-6255507 - OGL: use GL_EXT_framebuffer_object extension for improved performance
Description
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.
Comments
EVALUATION 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.
01-09-2005
WORK AROUND 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. ###@###.### 2004-02-24
24-02-2004
EVALUATION 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. ###@###.### 2004-02-24
24-02-2004