JDK-4884878 : IndexColorModel.getTransparentPixel() not returning -1 for ICMs w/o trans pixel
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: client-libs
  • Sub-Component: 2d
  • Priority: P2
  • Affected Version: 5.0
  • OS: solaris_8
  • CPU: sparc
  • Submit Date: 2003-06-27
  • Updated Date: 2017-05-16
  • Resolved Date: 2003-08-27
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 Availabitlity Release.

To download the current JDK release, click here.
5.0 tigerFixed
IndexColorModel.getTransparentPixel() is returning 0 instead of -1 for certain IndexColorModels that do not have a transparent pixel but have alpha.  
This is happening for ICMs created with the following constructors:
IndexColorModel(int, int, byte[], byte[], byte[], byte[]) ,
IndexColorModel(int, int, byte[], int, true), and
IndexColorModel(int, int, byte[], int, true, int trans) when trans is an invalid index (such as -1).

A test is attached that illustrates this problem.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b15 VERIFIED IN: tiger

EVALUATION Not clear if this is a bug. ICM is returning a transparent pixel. ###@###.### 2003-06-27 So the cases the jck tests are running into are: - if no tr.pixel is supplied, but the CM has transparency, we set a valid tr.pixel, if there's one (they assume it should always be -1, because they didn't set it) - if an invalid tr. pixel is supplied and CM has transparent pixels, we set a valid transparent pixel (they assume it should always be -1) Solution Clarify on what we understand under transparent pixel, and how we handle it in different situations. No changes to functionality is required. getTransparentPixel already implies that it might search out a transparent pixel since it doesn't define the term "the transparent pixel". That could mean "the pixel that we were told to force to be transparent in the constructor" or it could mean "the pixel which represents a transparent color". See CCC request: http://ccc.sfbay/4884878 The appropriate jck tests need to be updated to satisfy the new spec. ###@###.### 2003-07-24 ============================================ JCK tests have been updated and will be in b04 of the Tiger JCK. Fix verifies in b16 of Tiger JDK. ###@###.### 2003-08-27 ========================================

SUGGESTED FIX http://javaweb.sfbay/jcg/1.5.0-tiger/2D/4884878 ###@###.### 2003-07-24