United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6687298 Reg testcase java/awt/Graphics2D/DrawString/RotTransText.java fails in windows in pit build 6u10 b22
JDK-6687298 : Reg testcase java/awt/Graphics2D/DrawString/RotTransText.java fails in windows in pit build 6u10 b22

Details
Type:
Bug
Submit Date:
2008-04-11
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
client-libs
OS:
windows
Sub-Component:
2d
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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

Test was recently added as part of fix for 6683472.
                                     
2008-04-11
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.
                                     
2008-04-22



Hardware and Software, Engineered to Work Together