Hello, I wondered about the ddraw* tests, which show a similar message `Expect clip rect (0,0)-(1920,1080), got (0,0)-(1536,864).` over a range of Windows 10 machines.
This seems the same as discussed in: https://bugs.winehq.org//show_bug.cgi?id=54068 .
I searched just the internet for "1536,864" which also points to the direction of something DPI related.
So I tested if it disappears with a call to `SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE);`, and in seems it does. https://testbot.winehq.org/JobDetails.pl?Key=151556
(The failures with debiant and w11pro64_amd seem to be also there with a null patch: https://testbot.winehq.org/JobDetails.pl?Key=151557 )
Would such a change be acceptable, or would it defeat the purpose of the test?
From: Bernhard Übelacker bernhardu@mailbox.org
--- dlls/ddraw/tests/Makefile.in | 2 +- dlls/ddraw/tests/ddraw1.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/dlls/ddraw/tests/Makefile.in b/dlls/ddraw/tests/Makefile.in index 169a53d3974..6441220a203 100644 --- a/dlls/ddraw/tests/Makefile.in +++ b/dlls/ddraw/tests/Makefile.in @@ -1,5 +1,5 @@ TESTDLL = ddraw.dll -IMPORTS = ddraw user32 gdi32 ole32 +IMPORTS = ddraw user32 gdi32 ole32 shcore
SOURCES = \ d3d.c \ diff --git a/dlls/ddraw/tests/ddraw1.c b/dlls/ddraw/tests/ddraw1.c index 205370a8577..1d74492e29a 100644 --- a/dlls/ddraw/tests/ddraw1.c +++ b/dlls/ddraw/tests/ddraw1.c @@ -25,6 +25,7 @@ #include <math.h> #include "ddrawi.h" #include "d3dhal.h" +#include "shellscalingapi.h"
static BOOL is_ddraw64 = sizeof(DWORD) != sizeof(DWORD *); static DEVMODEW registry_mode; @@ -15942,6 +15943,8 @@ START_TEST(ddraw1) IDirectDraw *ddraw; HMODULE dwmapi;
+ SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE); + if (!(ddraw = create_ddraw())) { skip("Failed to create a ddraw object, skipping tests.\n");
Would such a change be acceptable, or would it defeat the purpose of the test?
I don't think it would defeat the purpose of the test, which was written before DPI scaling even existed. What does concern me is that, based on bug 54068, we don't know *why* this happens. The machines in question don't actually have any DPI scaling.
For instance, before we fix the tests, we should probably figure out if we need to replicate the same behaviour in Wine, and how to do so. This may imply there's something about DPI scaling in user32 we don't understand yet.