United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4424958 VolatileImage should have methods to enable volatile memory management
4424958 : VolatileImage should have methods to enable volatile memory management

Details
Type:
Enhancement
Submit Date:
2001-03-13
Status:
Resolved
Updated Date:
2001-08-09
Project Name:
JDK
Resolved Date:
2001-08-09
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

Related Reports

Sub Tasks

Description
VolatileImage objects can take up valuable and extrememly limited resources
such as VRAM.  For example, a typical laptop only has 4-8 Mb of VRAM
available, including that which the screen takes up.  If an application
reallocates many VolatileImages (for example, a resizing window may trigger
recreating the back buffer many times) then the application may run out
of system resources for some VolatileImages even though there should be
enough resources to contain all current/valid VolatileImages.

Garbage collection handles this for us, but the non-deterministic nature
of the garbage collector plus the limited size of some VRAM pools makes
this an imperfect solution for some applications.

There should be a means by which an application can manually release resources
taken up by a VolatileImage object, thus providing some guarantee to the
user of the amount of resources available at any given time.

-------------------------

In addition to the disposal proposal above, we should also have a means
of inquiring how much accelerated memory is available.  This would help
users of VolatileImage to determine how and when to allocate new objects
to most efficiently use the memory available.

chet.haase@Eng 2001-07-25

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
merlin-beta2

FIXED IN:
merlin-beta2

INTEGRATED IN:
merlin-beta2


                                     
2004-06-14
EVALUATION


Need to add the following methods:

VolatileImage.java:
	public void flush()

GraphicsDevice.java:
	public int getAvailableAcceleratedMemory()

The flush() method is actually already in VolatileImage; the method is
inherited from Image.java.  However, that method is currently stubbed out.
We need to define the new meaning of that method clearly in comments
and implement the code that makes this work.  An important concern in
implementing this functionality is MT-safety: we need to put new locks around
all ddraw surface accesses to make sure that other threads are not referring
to the underlying ddraw surface at the same time as we are releasing it.

The getAvailableAcceleratedMemory() would be a new method in GraphicsDevice.
The only trick in implementing this is that some platforms (i.e., NT4) do not
really support inquiries about video memory availability.  Our implementation
would need to trap that error case (where the free memory was always reported
as "0") and manually discover how much memory is there.  This can be done
by simply creating as many surfaces as possible (and then releasing
those temporary surfaces...) and reporting how many bytes were successfully
allocated.
                                     
2004-06-11



Hardware and Software, Engineered to Work Together