JDK-6687298 : Reg testcase java/awt/Graphics2D/DrawString/RotTransText.java fails in windows in pit build 6u10 b22
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2008-04-11
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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 Other
6u10Fixed 7 b28Fixed OpenJDK6Fixed
Related Reports
Relates :  
JDK-6683472 - Incorrect handling of translation component of font transform.
Description
The regression testcase java/awt/Graphics2D/DrawString/RotTransText.java
fails in windows with error "java.lang.RuntimeException: Unexpected color : ff0000ff at x=130 y=130"
with the latest pit build (6u10 b22).

Also fails with 1.4.2 b28 , and earlier 6u10 builds.

Its passing with 1.5.0 b64 build.

The error file has been attached (RotTransText.jtr)
Comments
EVALUATION Looks like this needs a tweak to the test. The bug for which this test verifies the fix manifested such that text was placed in wholly the wrong location when used with drawString vs TextLayout. The test is extremely strict in that it requires absolute pixel precision between the two regardless of transform. It appears that on windows, two particular rotations (30 and 150 degrees), show that a couple of the glyphs are off by one pixel, at 60 pt. This is due to floating point rounding differences in the two very different code paths. drawString takes the starting point of the text, and then positions each glyph at a rounded position, accumulating advances based on the font rasteriser's default x/y advances in the rotated strike. TextLayout uses the exact same strike to get the glyph images, but it assigns the positions of the glyphs itself, by taking the advances from the de-rotated strike, and then applying the device transform itself using Java double arithmetric performed by the AffineTransform class. The code that performs this is in sun.font.StandardGlyphVector.setupGlyphImage() Eg one case with drawString one glyph's y position ends up at 255.9998 and for TextLayout 256.0000. These values already had 0.5 added so that they could be rounded down, so that's not the problem. Its probably inevitable that some cases will differ by these tiny amounts. I think this will always recover and never be more than one pixel off. The probable fix is a single code path to determine the positions. So either always use drawString logic for a particular text string, or always use TextLayout. This is most likely to come out of optimisations of TextLayout to delegate to drawString for the simple cases, but that's not a foregone conclusion. The less probable solution is for TL to ensure its position calculations are 100% compatible with drawString. That seems like more trouble than its worth. The discrepancies are extremely small, and hard to detect. Its not easily humanly observable, and even in the automated case didn't manifest on Solaris SPARC - at least in this case. So the fix here will be to tweak the test to allow such extremely small deviations.
22-04-2008
EVALUATION Test was recently added as part of fix for 6683472.
11-04-2008