v2: - added patch "d3dx9/tests: Make test_ID3DXFont() less dependent on GetGlyphOutlineW(GGO_METRICS) behaviour." to fix the test failures introduced with v1.
The patchset actually changes nothing in ID3DXFont behaviour, the changes in test due to changes in GetGlyphOutlineW(GGO_METRICS) behaviour (which is used in test but not implementation). I did some investigation around this and I think the test breakage doesn't indicate that the MR is wrong but rather reflects some differences d3dx9 font implementation compared to Windows. First of all, all the same tests can be easily broken on Windows by using different font (e. g., Arial instead of Tahoma) and / or antialising quality in font, so the conditions which concerned tests assert are not generally satisified on Windows. The major difference in Windows implementation (which I think affects things as most here) is that Windows minds all the font antialiasing parameters (the same way, e. g., as if the text would be drawn with user32.DrawText). I displayed a test string rendered with ID3DXFont on screen through d3d9 presentation and I see Windows following quality parameter (e. g., drawing aliased with NONANTIALIASED_QUALITY). Behaviour in DRAFT_QUALITY is controlled by system parameter ("Performance Options / Smooth Edges of Screen Fonts" in SystemPropertiesPerformance.exe tool on Win10), changing this parameter affects whether antialiasing is present in ID3DXFont rendering. Wine d3dx9 currently always using antialiasing and requests glyphs with GGO_GRAY8_BITMAP, which is the major source of mismatch in these tests. If we want to make this behaviour closer match Windows me might probably use something like ExtTextOut() for rendering font instead of directly using glyph bitmap. But in that case this MR is prerequisite, the rendered image won't match the queried metrics without it.