-
Bug
-
Resolution: Fixed
-
P3
-
6
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2172680 | 6u14 | Andrew Brygin | P3 | Closed | Fixed | b02 |
OPERATING SYSTEM
----------------
Windows XP
FULL JDK VERSION
----------------
Any Java 6 SDK after pre-GA build 1.6.0-b92
DESCRIPTION
-----------
Direct printing quality with Java 6 is severely degraded, under certain circumstances, compared to Java 5.0. We have provided a testcase demonstrating this.
With the help of JLE (David Korbel) we have narrowed this problem down to a regression caused by the fix for CR 6444688 in 1.6.0-b92:
------- WPathGraphics.java -------
955a956,961
> * Since a subimage can be created by calling
> * BufferedImage.getSubImage() that condition needs to
> * be accounted for too. This implies inspecting the
> * data buffer. In the end too many cases are not able
> * to take advantage of this option until we can teach
> * the native code to properly navigate the data buffer.
966a973
> * Until all of this is resolved newImage is always true.
968,977c975
< int txType = rotTransform.getType();
< boolean newImage =
< (txType != AffineTransform.TYPE_IDENTITY &&
< txType != AffineTransform.TYPE_TRANSLATION) ||
< dibType != img.getType() ||
< icm != null && icm != img.getColorModel() ||
< srcX != 0 || srcY != 0 ||
< srcWidth != img.getWidth(null) ||
< srcHeight != img.getHeight(null);
<
---
> boolean newImage = true;
It seems that explicitly setting the boolean newImage to true is the root cause of the issue. If we change the code to always set the boolean to false, or reinstate the original code, the problem disappears. However, this will re-introduce the problem reported in 6444688. In summary, the fix for 6444688 needs to be reworked.
Release Regression From : 6
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
----------------
Windows XP
FULL JDK VERSION
----------------
Any Java 6 SDK after pre-GA build 1.6.0-b92
DESCRIPTION
-----------
Direct printing quality with Java 6 is severely degraded, under certain circumstances, compared to Java 5.0. We have provided a testcase demonstrating this.
With the help of JLE (David Korbel) we have narrowed this problem down to a regression caused by the fix for CR 6444688 in 1.6.0-b92:
------- WPathGraphics.java -------
955a956,961
> * Since a subimage can be created by calling
> * BufferedImage.getSubImage() that condition needs to
> * be accounted for too. This implies inspecting the
> * data buffer. In the end too many cases are not able
> * to take advantage of this option until we can teach
> * the native code to properly navigate the data buffer.
966a973
> * Until all of this is resolved newImage is always true.
968,977c975
< int txType = rotTransform.getType();
< boolean newImage =
< (txType != AffineTransform.TYPE_IDENTITY &&
< txType != AffineTransform.TYPE_TRANSLATION) ||
< dibType != img.getType() ||
< icm != null && icm != img.getColorModel() ||
< srcX != 0 || srcY != 0 ||
< srcWidth != img.getWidth(null) ||
< srcHeight != img.getHeight(null);
<
---
> boolean newImage = true;
It seems that explicitly setting the boolean newImage to true is the root cause of the issue. If we change the code to always set the boolean to false, or reinstate the original code, the problem disappears. However, this will re-introduce the problem reported in 6444688. In summary, the fix for 6444688 needs to be reworked.
Release Regression From : 6
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
- backported by
-
JDK-2172680 REGRESSION: Printing quality degraded with Java 6 compared to 5.0
-
- Closed
-
- relates to
-
JDK-6444688 Printing IndexColorModel images with a transparent pixel may fail on windows
-
- Resolved
-