JDK-2183443 : PNG reader should load RGB[A] images in display-optimal format
  • Type: Backport
  • Backport of: JDK-6549882
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2009-09-23
  • Updated: 2013-11-01
  • Resolved: 2009-10-06
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 6 JDK 7
6u18 b03Fixed 7Fixed
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u18/6549882
25-09-2009
EVALUATION Impact of loading and processing png images on startup time of the mediacenter benchmark can be estimated by a standalone java test which performs same set of image related actions on the same set of images, i.e. it loads and draws each of images used in the mediacenter application once. On test system average time of png images processing for 6u18 is basline: 396ms fix for 6549882: 289ms So, performance gain is about 111ms (about 28% of baseline time of png processing). This is in line with refworkload measurements for benchmark itself: ============================================================================== c:\tmp\mediacenter_orig2.res: Benchmark Samples Mean Stdev Geomean Weight startup2 20 6185.85 21.62 ============================================================================== c:\tmp\mediacenter_backport.res: Benchmark Samples Mean Stdev %Diff P Significant startup2 20 6071.95 13.58 1.84 0.000 Yes ============================================================================== Note that even if image loading will take 0ms it is only 6% of total startup time for this benchmark. Much less then 20% estimate we got before and which was likely wrong estimate. Splitting total imaging-related time into loading and drawing: before fix: 396ms = 185ms + 211ms with fix: 289ms = 195ms + 94ms Note that parsing time has been increased. This happens because we can not use arraycopy after fix as bytes needs to be reordered. We plan to investigate whether we can improve here. This will be tracked as bug 6879279.
23-09-2009