United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4330166 Need API for accelerated offscreen surfaces
JDK-4330166 : Need API for accelerated offscreen surfaces

Details
Type:
Enhancement
Submit Date:
2000-04-13
Status:
Resolved
Updated Date:
2001-07-31
Project Name:
JDK
Resolved Date:
2001-07-31
Component:
client-libs
OS:
windows_nt
Sub-Component:
2d
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.0 (beta2)

Related Reports
Duplicate:
Duplicate:

Sub Tasks

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
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
                                     
2000-10-20
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
merlin-beta

FIXED IN:
merlin-beta2

INTEGRATED IN:
merlin-beta2


                                     
2004-06-14



Hardware and Software, Engineered to Work Together