Currently, there are 2 different means for accessing hardware acceleration for
imaging operations: explicit image acceleration via the VolatileImage object and implicit acceleration for other types of Image objects.
1) Update the VolatileImage API
The VolatileImage class is a way for developers to specify that they want
a particular image to be cached in accelerated memory if possible. Rendering
operations to and from that image will be hw-accelerated to the extent possible for a given combination of rendering operations and runtime configuration. The problem with VolatileImage currently is that developers can only create an opaque VolatileImage, with the APIs:
GraphicsConfiguration.createCompatibleVolatileImage(w, h, caps)
With current and future capabilities of Java2D to accelerate both transparent
and translucent images, we need to provide API that allows developers to
create a VolatileImage with transparency or translucency.
2) Update the Image API
Images that are not VolatileImage objects can also benefit from hardware
acceleration. In certain situations, Java2D may create a hardware-cached version of an Image that may then be used for various rendering operations. For example, a Swing icon created with GraphicsConfiguration.createCompatibleImage() may end up being cached in VRAM on Windows and that hw-based image can then be used for hw-accelerated copies to the Swing back buffer.
The problem is that developers have no way of querying the state of an image or of affecting our internal acceleration scheme. Because graphics acceleration resources can be very limited (for example, video cards with only 8MB or less of VRAM), finer control is needed to get optimal acceleration for certain applications.
We need the ability to do 2 things for arbitrary Images to allow this finer control:
- query the current acceleration state of any given Image
- set a hint for a given Image that tells Java2D how to prioritize the acceleration for that Image, relative to other Image objects.