JDK-4330166 : Need API for accelerated offscreen surfaces
  • 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: 2000-04-13
  • Updated: 2001-07-31
  • Resolved: 2001-07-31
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.
Other
1.4.0 beta2Fixed
Related Reports
Duplicate :  
JDK-4379980 - VolatileImage needs better support for multimon
Duplicate :  
JDK-4379971 - VolatileImages cannot subclass BufferedImage
Description
In order to get hardware acceleration for offscreen surfaces (such as those
used for sprites and double-buffering), we need a new API that allows us
to work with such objects.  In particular, these types of hardware-accelerated
surfaces are more volatile than existing Java images, and their contents 
could be destroyed at any time by circumstances beyond the control of
Java or the application.

We need new API calls that allow us to both create these kind of surfaces
(telling Java that we want that particular image to be accelerated 
if possible) and deal with potential content-loss problems (ways for the
user to know that contents have been lost and the means of restoring them).

-----------
There are additional requirements for this API, as specified in RFE's
4379971 and 4379980.  I am closing those RFE's as duplicates of this one and
reopening this RFE.  The descriptions from those RFE's follows:

4379971:
Currently, the new VolatileImage objects are implemented as subclasses
of BufferedImage.  This causes a problem with the specification of 
BufferedImage.  In particular, a BufferedImage is created as a static object
(with a static ColorModel, Raster, and SampleModel), whereas a VolatileImage
can change at any time due to situations such as display mode switches.

For example, if a user changes the bit depth setting (under Windows) we must
recreate the data inside of the VolatileImage to be compatible with this
new display depth (hardware surfaces must always be the same depth as the
display surface).

Because of this incompatibility, we need to make VolatileImage objects
subclass off of Image instead, so that the user can assume nothing about
the state or static nature of the image.

4379980:
VolatileImage currently has no means to help the user support multi-
monitor situations.  The problem is that VolatileImage objects are inherently
tied to the device on which they were created (e.g., the video card of
a particular display on Windows).  When an app asks the VolatileImage to 
copy its contents to a different device (for example, if the app window
moved to a different monitor or the app attempts to use one back buffer
for several windows), this operation could fail but there is no way for
VolatileImage to tell the user why it failed or what to do about it.


chet.haase@Eng 2000-10-20
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004
EVALUATION The API needed here is: - createVolatileImage() method calls, in addition to the existing createImage() calls - New interface, VolatileImage, that is implemented by the object returned by createVolatileImage(). This object would have methods that allow the user to validate the image (ensure that the drawing surface exists on the hardware, which causes it to be restored if it was lost), and to query whether the contents have been lost since the last validation of the image. -------- Following are the evaluations from RFE's 4379971 and 4379980: 4379971: First of all, change VolatileImage from an interface to a class. This makes using the methods of VolatileImage easier, as the user does not have to cast the object into either an Image or VolatileImage to get the functionality they want. More importantly, make this class subclass directly off of Image instead of BufferedImage. 4379980: Currently, the validate() method of VolatileImage takes no arguments and is responsible purely for restoring or recreating the image surface, if it is in a lost state. We should enhance the validate() method to take a GraphicsConfiguration object as an input parameter. The method could then check whether the current VolatileImage object is compatible with this GC. If so, it restores the surface as before and returns a message to the app telling whether the image was ok or restored. If not, it returns a message to the user that the image is incompatible with the given GC; at this point the user app can decide what to do about the situation (presumably use some other VolatileImage object or create a new one for this purpose). This approach would allow us to tell the user about failures before they happen and to inform them with e3nough details that they can hopefully correct the problem and then try again. chet.haase@Eng 2000-10-20
20-10-2000