JDK-6205557 : Changes to image data should be tracked at a finer granularity
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2,5.0,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,solaris_9
  • CPU: generic,x86
  • Submitted: 2004-12-08
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
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.
JDK 7 Other
7 b08Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
JDK-6231864 - Some images loaded via Toolkit or ImageIcon can't be accelerated
Relates :  
JDK-6528166 - regression: calling drawImage() results in java.lang.NullPointerException in jdk7.0 b08
Relates :  
JDK-6529933 - REG: Deadlock when running a fullscreen test on SuSE 10 with Nvidia
Relates :  
JDK-6615272 - D3D: Some images loaded via Toolkit or ImageIcon can't be accelerated
Relates :  
JDK-6518385 - exception thrown from RescaleOp.filter(bimg, bimg)
Relates :  
JDK-4835595 - PixelGrabber.grabPixels runs up to 600 times slower on JDK1.4.1 than on JDK1.3.1
Description
The graphics implementation tracks changes to image objects so that it
can determine when to cache the data in an accelerated surface and when
those cached versions are out of date.

Currently that tracking is performed at the Raster level and requires
strict ownership of the DataBuffer and the data arrays in the DataBuffer.
This means that any code that attempts to dig into an image to get its
DataBuffer or any attempt to create multiple Rasters and Images which
share a DataBuffer will result in those images being ineligible for
acceleration via our CachingSurfaceManager.

Various proposals have been suggested to turn off this mechanism and make
the default assumption that all image data is cacheable regardless of
how exposed the pixel data is because the existing mechanism will be
unable to track the changes under a variety of circumstances that turn
out to be common or important to a growing number of developers.

Also, change tracking is only available via the internal hidden Raster
classes in the sun.* hierarchy which cannot be accessed by code outside
the JDK.

If the tracking is moved to a lower layer then more interfaces in the
java.awt.image package could be used by developers without the undesired
result of yielding unacceleratable images.  Minimally this involves:

- Moving the change tracking down into the DataBuffer class from the
internal SunWritableRaster classes.

- Providing an interface for modifying the pixels in an image - presumably
at the DataBuffer level - that interacts well with the change tracking
mechanisms with reasonable performance.

- Verifying that the code in the JDK is "change tracking compatible" by
finding cases where we currently violate the assumptions of the current
change tracking mechanism and making sure that they will be compatible
with the assumptions of the new mechanism.  This implicitly assumes that
we will also verify that we have created no new cases which violate the
new rules of the new change tracking mechanism.
###@###.### 2004-12-08 02:05:11 GMT
###@###.### 2004-12-08 02:37:01 GMT
Comments
EVALUATION Note that this fix caused a regression as detailed in bug 6528166. The fix was to test for a null accelData before looking for and setting up the transparent pixel on it.
05-04-2007
EVALUATION Note that this fix caused a regression in the RescaleOp filter as detailed in bug 6518385. The fix was to add an explicit null check on the return value of the ImagingLib.
05-04-2007
EVALUATION Note that this bug caused a regression as detailed in bug 6529933. The fix was to synchronize X11GraphicsDevice.getProxyKeyFor() on the HashMap instead of on the X11GraphicsDevice class.
05-04-2007
EVALUATION DataBuffer Objects will now have a built-in hidden "StateTrackable" object which allows multiple parties to track changes to them. This hidden object is used internally to test to see if the data has been "stolen" (i.e. a reference to the internal Java array holding the pixels was handed out for instance), or if it has been modified since the last inspection. SurfaceData objects also use this same mechanism now to track their changes, both to their pixel data and also to any of their status flags like "surfaceLost" or "valid". The SurfaceData for a BufferedImage will use the Trackable object from its associated DataBuffer as its Trackable. Other SurfaceData objects will create their own Trackable. These changes allowed us to remove the old RasterListener implementation and overrides since parties interested in changes to image data can use the Tracker now instead of having to listen for changes. The net performance impact of these changes is negligible for BufferedImage objects since there is so much processing going on in addition to the changes to the DataBuffer data and also because they used to be penalized for modifying the Raster by the old RasterListener notifications and now they trade those off for a somewhat simpler dirty mechanism in the DataBuffer itself. The changes can be a win for modifying Raster objects since the new mechanism is lighter weight than the older notification mechanism, especially when there is a Listener installed in the Raster. The changes can be a loss for modifying DataBuffer objects directly since there used to be no mechanism for tracking those changes. The slight loss in performance of the DataBuffer objects was deemed acceptable since new mechanisms can be created to amortize the dirty mechanism over the modification of many pixels and also because it used to be the case that merely fetching the DataBuffer object out of an image would cause it to become permanently de-accelerated. With the new mechanism the acceleration is only lost if you grab the Java array directly, but you can now call DataBuffer.setElem methods and still be accelerated.
26-01-2007
EVALUATION We are investigating some modifications to the DataBuffer classes to facilitate change tracking at that level. This should increase the number and types of images that we can accelerate through caching. At the same time we will evaluate the existing DataBuffer methods to modify pixels and see if they perform reasonably well compared to direct modification of the data array. Further API may be needed if those methods do not perform adequately. ###@###.### 2004-12-08 02:37:01 GMT
08-12-2004