This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2016-09-23 21:59:55 +0000, Ethan Lee wrote:

We've encountered a really odd case on Windows where GetCurrentDisplayMode doesn't actually report the desktop resolution. Using this test program...

int main(int argc, char **argv)
{
SDL_DisplayMode mode;
int modes;
int i;

SDL_Init(SDL_INIT_VIDEO);
modes = SDL_GetNumDisplayModes(0);
for (i = 0; i < modes; i += 1)
{
    SDL_GetDisplayMode(0, i, &mode);
    printf("%d %d\n", mode.w, mode.h);
}
SDL_GetCurrentDisplayMode(0, &mode);
printf("%d %d\n", mode.w, mode.h);
SDL_Quit();
return 0;

}

... you'll get the following on a LG 55EG9100 running at 1920x1080, using an AMD GPU on Windows 10:

1920 1080
1920 1080
1920 1080
1920 1080
1920 1080
1920 1080
1776 1000
1776 1000
1776 1000
1776 1000
1776 1000
1680 1050
1680 1050
1680 1050
1680 1050
1680 1050
1680 1050
1600 900
1600 900
1600 900
1600 900
1600 900
1360 768
1280 1024
1280 960
1280 768
1280 720
1280 720
1152 864
1152 648
1152 648
1024 768
800 600
720 576
720 480
720 480
640 480
640 480
1280 720

The expected behavior is that we get '1920 1080' as the last line instead of '1280 720'.

On 2016-10-29 22:57:39 +0000, Hayk Shahparonyan wrote:

The problem should be due to Windows DPI scaling. If you've set you resolution to 1920x1080 and it was scaled by 150%, you will get 1280x720 reported to SDL. I either did not get any solution for this either, so I hope to see some actions (like an API to get real resolution) from developers.

On 2016-10-31 16:27:18 +0000, Ethan Lee wrote:

Looks like that was it. Is there any way for us to sidestep this issue, or is there a way we can query scale and adjust the resolution accordingly?

On 2016-10-31 16:42:03 +0000, Alex Szpakowski wrote:

I believe the "correct" approach (which would also benefit iOS and macOS) is to provide a new API to query the pixel size or scale factor for display modes, since if you're working with high dpi aware stuff it usually makes sense to know both the raw pixel dimensions and the pixel density scaled dimensions.

On 2018-09-05 16:44:44 +0000, Ethan Lee wrote:

Closing this since the issue is known to be fixed by either a manifest file or something like SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE), falling back to SetProcessDPIAware() for older Windows versions. Maybe SDL can provide an SDL_Windows_SetProcessDPIAware() function that automatically does all this, but the main thing is that this is technically intentional behavior on Windows' part.