-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P4
-
Affects Version/s: 8
-
Component/s: client-libs
-
b08
-
x86
-
windows_7
FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
In javax.swing.plaf.nimbus.DerivedColor.rederiveColor, the hue/sat/brightness values are clamped to a 0 to 1 range after adding the offsets.
This is incorrect for hue, since hues are cyclic. With the current implementation, large hue offsets will cause any hue to become red. This probably doesn't affect any existing code since Nimbus is mainly blue-grey-coloured, but it's still wrong.
There is no need to apply clamping or wrapping logic to the hue value here, since java.awt.Color.HSBtoRGB already converts hues to a cyclic 0 to 1 range.
REPRODUCIBILITY :
This bug can be reproduced always.
A DESCRIPTION OF THE PROBLEM :
In javax.swing.plaf.nimbus.DerivedColor.rederiveColor, the hue/sat/brightness values are clamped to a 0 to 1 range after adding the offsets.
This is incorrect for hue, since hues are cyclic. With the current implementation, large hue offsets will cause any hue to become red. This probably doesn't affect any existing code since Nimbus is mainly blue-grey-coloured, but it's still wrong.
There is no need to apply clamping or wrapping logic to the hue value here, since java.awt.Color.HSBtoRGB already converts hues to a cyclic 0 to 1 range.
REPRODUCIBILITY :
This bug can be reproduced always.