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:
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
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.
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.