-
Bug
-
Resolution: Fixed
-
P3
-
1.4.2, 5.0, 6
-
b08
-
generic, x86
-
generic, linux, solaris_9
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2152909 | OpenJDK6 | Philip Race | P2 | Resolved | Fixed | b02 |
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
- backported by
-
JDK-2152909 Changes to image data should be tracked at a finer granularity
-
- Resolved
-
- duplicates
-
JDK-6231864 Some images loaded via Toolkit or ImageIcon can't be accelerated
-
- Closed
-
- relates to
-
JDK-6518385 exception thrown from RescaleOp.filter(bimg, bimg)
-
- Closed
-
-
JDK-6528166 regression: calling drawImage() results in java.lang.NullPointerException in jdk7.0 b08
-
- Closed
-
-
JDK-6529933 REG: Deadlock when running a fullscreen test on SuSE 10 with Nvidia
-
- Closed
-
-
JDK-4835595 PixelGrabber.grabPixels runs up to 600 times slower on JDK1.4.1 than on JDK1.3.1
-
- Closed
-
-
JDK-6615272 D3D: Some images loaded via Toolkit or ImageIcon can't be accelerated
-
- Closed
-