On Sat, 20 Sep 2025 23:55:39 GMT, Sergey Bylokhov <[email protected]> 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. FYI there was already an open bug on this : https://bugs.openjdk.org/browse/JDK-8347618 Granted that bug mentions 24.10, not 24.04 but it is likely the same. Your bug reports "The failure is due to 198 different pixels. This is out of a total of 3434 "non-white" pixels in each image." The older bug reports "nonWhite image 1 = 3434 nonWhite image 2 = 3434 Number of non-white differing pixels=198" Pretty similar I'd say. I've run your fix on our CI systems but I want to run it on my physical 24.04 system - which I can't do today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27407#issuecomment-3344105642
