RFR: 8362204: test/jdk/sun/awt/font/TestDevTransform.java fails on Ubuntu 24.04

Alexey Ushakov avu at openjdk.org
Mon Sep 22 08:58:22 UTC 2025


On Sat, 20 Sep 2025 23:55:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This test verifies rendering consistency across three APIs: String, TextLayout, and GlyphVector. The same text is rendered using each API, and the results are expected to match.
> 
> The test logic differs slightly between the two cases:
> String rendering:
> 1. Create surface, set scale, hint, and font
> 2. Apply translate, rotate, and scale transform
> 3. Draw the String
> 
> TextLayout/GlyphVector rendering:
> 1. Create surface, set scale, hint, and font
> 2. Create a FontRenderContext
> 3. Build a GlyphVector or TextLayout with the render context for the surface above
> 4. Apply translate, rotate, and scale transform
> 5. Draw the GlyphVector/TextLayout
> 
> The issue is that the String variant produces slightly different glyph positions compared to TextLayout/GlyphVector. The glyph shapes are correct, but they are shifted. This occurs in several cases:
>  - With both antialiasing and fractional metrics enabled
>  - When the dialog font is used (monospaced fonts are fine)
>  - When mixing float and double in scaling:  "g2d.scale(1.481f, 1.481)"
> 
> The issue does not occur:
>  - If the transform order is changed (scale <--> translate <--> rotate).
>  - When numbers are tweaked.
> 
> I think the main issue is that the test applies transforms in a different order for String versus TextLayout/GlyphVector. These operations are not strictly equivalent, so small differences are expected. So I have modified the test:
>  - Replaced mixed float + double scaling with consistent use of just float or double
>  - Add coverage for monospaced fonts
> Now, if failures occur, we can problemlist individual subtest instead of disabling the entire test.

LGTM

-------------

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27407#pullrequestreview-3251265412


More information about the client-libs-dev mailing list