JDK-4775930 : PIT:REG: ImageIO rendering failures for some BufferedImage types
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2002-11-08
  • Updated: 2002-11-12
  • Resolved: 2002-11-12
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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4732249 - Performance and cleanup work on clipping implementation
Relates :  
JDK-4776610 - PIT:REG: Exception when converting some PNG images to BufferedImage.TYPE_INT_ARG
Description
With the Java2D 05-Nov-02.mantis build we are observing several failures with image rendering, especially with png image files.  The rendering is a blank image.

- The failures have been seen on both Solaris and Win32 platforms.
- The bug is not reproducable with the last Mantis promoted build:  1.4.2-beta-b06

1) ImageIO (jtreg) Suite/Interactive Tests
- Interactive/QL/Render2DTest
- Interactive/QL/GetImageReaderTest
- Interactive/QL/FileCacheImageOutputStreamTest

2) MediaServer GoldenRetriever.java application is unable to render PNG images read from local directory.

Attaching test application ImgReadWrite.java which will allow the bug to be reproduced on supported BufferedImage types.

Here's a summary of results for rendering PNG and JPG images on various BufferedImages:

png-Shape
=========

Fails - no rendering
--------------------
TYPE_INT_RGB
TYPE_INT_ARGB
TYPE_INT_ARGB_PRE
TYPE_INT_BGR
TYPE_3BYTE_BGR
TYPE_4BYTE_ABGR
TYPE_4BYTE_ABGR_PRE
TYPE_USHORT_565_RGB
TYPE_USHORT_555_RGB

Passes
------
TYPE_BYTE_GRAY
TYPE_USHORT_GRAY
TYPE_BYTE_BINARY
TYPE_BYTE_INDEXED

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

jpeg-Shape
==========

Fails - no rendering
--------------------
TYPE_INT_ARGB
TYPE_INT_ARGB_PRE
TYPE_4BYTE_ABGR
TYPE_4BYTE_ABGR_PRE


Passes
------
TYPE_INT_RGB
TYPE_INT_BGR
TYPE_3BYTE_BGR
TYPE_USHORT_565_RGB
TYPE_USHORT_555_RGB
TYPE_BYTE_GRAY
TYPE_USHORT_GRAY (test bug)
TYPE_BYTE_BINARY
TYPE_BYTE_INDEXED
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b07
14-06-2004
EVALUATION This failure was caused by the clipping changes (4732249) that were putback on 10/24. As of that putback we now handle all clipping (simple/complex) in the *Blit* subclasses via Regions. The source of this failure is in the general (backup) blitting methods in CustomComponent.java and their use of the Java-level RegionSpanIterator to iterate the clip Region. In the new version of Region, if the clip region is rectangular (simple), the bands array is null and endIndex is 0. The older RegionIterator assumes that there will be at least one span in the Region bands list, as there was in the older version. So RegionSpanIterator.nextSpan() uses the methods in RegionIterator, which essentially report that there are no spans (because Region.endIndex == 0) and nextSpan() returns false. The inner loop of OpaqueCopyAnyToArgb never gets executed, and therefore nothing is rendered, as was reported in the description above. The fix is to detect in RegionSpanIterator.nextSpan() whether the Region is rectangular, and if so update the span box with the bounds of the Region and return true (making sure to set the done flag so that the next time nextSpan() is called, we automatically return false). ###@###.### 2002-11-07
07-11-2002