JDK-4881082 : Need more API for controlling hardware acceleration of images
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2003-06-19
  • Updated: 2017-05-16
  • Resolved: 2003-08-18
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 Availabitlity Release.

To download the current JDK release, click here.
5.0 tigerFixed
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:
	Component.createVolatileImage(w, h)
	GraphicsConfiguration.createCompatibleVolatileImage(w, h)
	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.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16

EVALUATION 1) Update VolatileImage API: GraphicsConfiguration.createVolatileImage(int w, int h, int transparency); This method parallels a similar method with non-Volatile image creation in GraphicsConfiguration. This new method would allow developers to explicitly create a VolatileImage object that may be transparent or translucent. Note that the existence of this method does not guarantee that the resulting VolatileImage will be hardware-accelerated; that depends on the implementation of the method on a given platform as well as the runtime configuration. 2) Update the Image API: a) Allow querying of Image capabilities Move the method: ImageCapabilities VolatileImage.getImageCapabilities(); to the Image superclass: ImageCapabilities Image.getImageCapabilities(); The resulting capabilities object could be queried to find out whether a given Image (Volatile or non-Volatile) was currently accelerated. b) Allow prioritization of Image acceleration: void Image.setPriority(float priority) This method would set a priority hint for any given Image. Internally, we would use this value to determine: - whether to accelerate the image at all (a value of 0 tells us not to bother) - whether this Image takes priority over other Image objects in the system. In a constrained-resource situation (such as insufficient VRAM to store an Image), an Image of higher priority could force one of lower priority to be de-accelerated. This method would give developers a chance to tell Java2D to "do the right thing" with regard to prioritizing implicit image acceleration when we cannot simply accelerate everything. ###@###.### 2003-06-19 Also need a matching getPriority() method in Image so that anyone (including internal classes) can inquire the current value for a given Image. ###@###.### 2003-06-19