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.
|
Java