https://bugs.winehq.org/show_bug.cgi?id=51989
Bug ID: 51989 Summary: pen-related tests (gdiplus:graphics and gdiplus:graphicspath) fail on latest Windows 10 Product: Wine Version: 6.17 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs@winehq.org Reporter: madewokherd@gmail.com Distribution: ---
We had some new test failures appear in Windows 10 on November 2.
https://test.winehq.org/data/20f1a677b664b3d0d3dc038ffb9ab4f4e4aa6274/win21H... https://test.winehq.org/data/20f1a677b664b3d0d3dc038ffb9ab4f4e4aa6274/win21H...
It appears that Pen objects with a width of 0.0 and a unit of UnitPixel now draw with 1.0 width. Previously, they did not draw.
Pen objects with UnitWorld would always draw with a minimum width of 1.0, so possibly this brings other units' behavior in line with UnitWorld.
The C# and C++ wrappers only allow creating Pen objects with UnitWorld, other units can only be used through the C API.
We also had the following Mono tests start failing around the same time: MonoTests.System.Drawing.PenTest:Constructor_Brush_Float_Negative MonoTests.System.Drawing.PenTest:Constructor_Brush_Float_Zero MonoTests.System.Drawing.PenTest:Constructor_Color_Float_Negative MonoTests.System.Drawing.PenTest:Constructor_Color_Float_Zero MonoTests.System.Drawing.PenTest:Width
In these cases, the test creates a UnitWorld Pen with width < 1.0 and expects to get the same width back. Instead, current native gdiplus reports a width of 1.0.
I'm not sure whether we should update to this new behavior. It seems likely to cause a regression if it applies to other units (a half-pixel Pen doesn't make much sense, but half-inch Pen does).
https://bugs.winehq.org/show_bug.cgi?id=51989
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com Keywords| |download, testcase
https://bugs.winehq.org/show_bug.cgi?id=51989
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source OS|Linux |Windows CC| |fgouget@codeweavers.com
--- Comment #1 from François Gouget fgouget@codeweavers.com --- I can confirm this. I traced it back to KB5006670 which does not help much because it's a bundle of many updates. One element is that gdiplus.dll goes from version 10.0.19041.1151 to >= 10.0.19041.1288.
Note that: * w10pro64 got upgraded from 2004 to 21H1 on 2021-10-21 which is when it started these tests started failing for this VM. * cwgtx560 and cw-rx460 were already on 21H1 but got upgraded on 2021-11-02 which is when they got KB5006670 which also matches when the tests started failing.
For future reference here are the new failures:
gdiplus:graphics https://test.winehq.org/data/patterns.html#gdiplus:graphics
graphics.c:4143: Test failed: 1: expected 0, got 1 graphics.c:4168: Test failed: 1: expected 0, got 1
gdiplus:graphicspath https://test.winehq.org/data/patterns.html#gdiplus:graphicspath
graphicspath.c:1450: Test failed: Expected 00000000, got 00000004 graphicspath.c:1714: Test failed: Path size 12 does not match expected size 8 graphicspath.c:1714: Test failed: Expected #0: PathPointTypeStart (6.4,8.6) but got PathPointTypeStart (5.0,9.5) graphicspath.c:1714: Test failed: Expected #1: PathPointTypeLine (6.4,11.4) but got PathPointTypeLine (50.0,9.5) graphicspath.c:1714: Test failed: Expected #2: PathPointTypeLine (3.6,11.4) but got PathPointTypeLine (50.0,10.5) graphicspath.c:1714: Test failed: Expected #3: PathPointTypeLine | PathPointTypeCloseSubpath (3.6,8.6) but got PathPointTypeLine | PathPointTypeCloseSubpath (5.0,10.5) graphicspath.c:1714: Test failed: Expected #4: PathPointTypeStart (48.6,11.4) but got PathPointTypeStart (6.4,8.6) graphicspath.c:1714: Test failed: Expected #5: PathPointTypeLine (48.6,8.6) but got PathPointTypeLine (6.4,11.4) graphicspath.c:1714: Test failed: Expected #6: PathPointTypeLine (51.4,8.6) but got PathPointTypeLine (3.6,11.4) graphicspath.c:1714: Test failed: Expected #7: PathPointTypeLine | PathPointTypeCloseSubpath (51.4,11.4) but got PathPointTypeLine | PathPointTypeCloseSubpath (3.6,8.6)
https://bugs.winehq.org/show_bug.cgi?id=51989
--- Comment #2 from Esme Povirk madewokherd@gmail.com --- Testing the Pen width getter should be an easy way to detect the new version. Could we have a function that checks that and put any todos/brokens in there while the rest of the tests just change their expectations based on that? It seems like a hassle to account for different behaviors everywhere and potentially have to change the annotations individually.
https://bugs.winehq.org/show_bug.cgi?id=51989
--- Comment #3 from Esme Povirk madewokherd@gmail.com --- Apparently my Windows 10 VM has updated Pen Width reporting behavior (Width set to <1 is reported as 1), but not the new rendering behavior. So I can't use that to check.
The VM is 21H1, and I have gdiplus.dll version 10.0.19041.1348. The gdiplus tests pass in my VM as-is.
https://bugs.winehq.org/show_bug.cgi?id=51989
--- Comment #4 from Esme Povirk madewokherd@gmail.com --- Do any of the failing VMs have a gdiplus.dll that's at least as new as that one? If not, maybe we should assume this behavior caused a regression in Windows and was backed out.
https://bugs.winehq.org/show_bug.cgi?id=51989
--- Comment #5 from Esme Povirk madewokherd@gmail.com --- Here we go. I got the new version from KB5007885: https://support.microsoft.com/en-us/topic/november-9-2021-kb5007186-os-build...
"Addresses an issue in which certain apps might have unexpected results when rendering some user interface elements or when drawing within the app. You might encounter this issue with apps that use GDI+ and set a zero (0) width pen object on displays with high dots per inch (DPI) or resolution, or if the app is using scaling."
So this is broken behavior that MS shipped and later fixed.
https://bugs.winehq.org/show_bug.cgi?id=51989
--- Comment #6 from Esme Povirk madewokherd@gmail.com --- Created attachment 71108 --> https://bugs.winehq.org/attachment.cgi?id=71108 patch marking the new results broken
Submitted as testbot job: https://testbot.winehq.org/JobDetails.pl?Key=102566
I'm not sure if testbot ran the updated graphicspath tests, or if any of these are the affected machines.
https://bugs.winehq.org/show_bug.cgi?id=51989
--- Comment #7 from Esme Povirk madewokherd@gmail.com --- I can already see that I messed that up by putting a broken() in an expect().
https://bugs.winehq.org/show_bug.cgi?id=51989
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #71108|0 |1 is obsolete| |
--- Comment #8 from Esme Povirk madewokherd@gmail.com --- Created attachment 71109 --> https://bugs.winehq.org/attachment.cgi?id=71109 patch marking the new results broken
New testbot job: https://testbot.winehq.org/JobDetails.pl?Key=102569
https://bugs.winehq.org/show_bug.cgi?id=51989
--- Comment #9 from Esme Povirk madewokherd@gmail.com --- Since this passes w10pro64 and on my local machines, I went ahead and sent it: https://www.winehq.org/pipermail/wine-devel/2021-November/201552.html
https://bugs.winehq.org/show_bug.cgi?id=51989
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |28c35689d2d9193cbf7ce5f523f | |ecbaf377ae273 Status|NEW |RESOLVED
--- Comment #10 from Esme Povirk madewokherd@gmail.com --- The patch was committed.
https://bugs.winehq.org/show_bug.cgi?id=51989
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.23.