On Tue Nov 21 08:13:16 2023 +0000, Paul Gofman wrote:
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.
Font rendering isn't exactly my specialty so I want to be sure I understand the issue here. BTW, you don't need to go and find an answer to all my questions, I'm just trying to dump your brain WRT what you already found out :sweat:
In particular, you mention font quality affecting d3dx9 output with native but not with our implementation. How does that work exactly? Notice that we pass the quality setting over to CreateFontW(). Is that not enough? Is GGO_GRAY8_BITMAP just not right for non-antialiased fonts? Or is it a case where things don't work properly unless you draw the whole string at the same time? The DRAFT_QUALITY thing seems mostly orthogonal to d3dx9, as I understand it.
I expect these tests to generally have room for improvement. From what I understand from your results, right now they're effectively passing by chance. So, while adding a few todo_wine to keep the tests passing might be okay for the time being, I'd prefer to fix the tests (which might even mean getting rid of a few of them) or at least figure out what needs to be fixed. It would be unfortunate to mark some test as todo_wine, implying that the implementation is broken, when in fact it's the test that's "too strict", for some definition of it.
Looking at the whole MR, would it make sense to pass GGO_GRAY8_BITMAP to the GetGlyphOutlineW() calls in the d3dx9 tests? Or is that how you found out that the implementation is not correct in that regard?