United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4881082 Need more API for controlling hardware acceleration of images
JDK-4881082 : Need more API for controlling hardware acceleration of images

Details
Type:
Enhancement
Submit Date:
2003-06-19
Status:
Resolved
Updated Date:
2003-08-18
Project Name:
JDK
Resolved Date:
2003-08-18
Component:
client-libs
OS:
windows_nt
Sub-Component:
2d
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
5.0 (tiger)

Related Reports

Sub Tasks

Description
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)
and
	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.

                                    

Comments
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
                                     
2003-06-19
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b16


                                     
2004-06-14



Hardware and Software, Engineered to Work Together