SDL_GetDesktopDisplayMode() behavior with High DPI modes is inconsistent across platforms

[cgutman]

SDL_GetDesktopDisplayMode() returns different results for the same display when using DPI scaling on various platforms.

On Windows, it returns the true display resolution, ignoring any DPI scaling. On macOS and Wayland, it returns a resolution that includes the DPI scaling factor.

For example, with a 3840x2160 display configured to run at 200% scaling, SDL_GetDesktopDisplayMode() would return:

• 3840x2160 on Windows
• 1920x1080 on macOS
• 1920x1080 on Wayland

I'm not sure which result is actually what we want, but we should probably be consistent either way. Depending on which way we go, SDL_GetUnscaledDesktopDisplayMode() or SDL_GetScaledDesktopDisplayMode() would be nice to have the other option available.

Additionally, it would be nice to have a SDL_GetNativeDisplayMode() for cases where the application just wants to know the native screen resolution (which might not be the desktop display mode).

[peppy]

I'm not sure on the expectations of SDL_GetDesktopDisplayMode, but we currently use SDL_GL_GetDrawableSize to get the post-scaled resolution, and SDL_GetWindowSize to get the "true" resolution, and it seems to work quite reliably for us across all platforms mentioned.

An example of our usage to find the DPI scale ratio:

https://github.com/ppy/osu-framework/blob/0b11c061376346d4aa0d7598af496223c1a91eae/osu.Framework/Platform/SDL2DesktopWindow.cs#L593-L601

[slouken]

@cgutman, have you tried setting the new hint SDL_HINT_WINDOWS_DPI_SCALING? That's intended to make Windows in line with the other platforms in how it handles coordinates and DPI scaling.

[cgutman]

Enabling SDL_HINT_WINDOWS_DPI_SCALING doesn't seem to change that particular behavior (though it does fix the windows being too small on High DPI systems).

[flibitijibibo]

Adding iOS to the mix: #5290

Personally I wouldn't be opposed to a function like SDL_GetDisplaySizeInPixels that shows the maximum resolution and ignores all OS scaling - it would address our needs and would allow the other display calls to keep thinking in terms of logical size, which is more appropriate anyhow (the exception being when you enable high-DPI, and at that point you pretty much know what you're getting into when it comes to logical/pixel mismatches).

[a-hurst]

Adding iOS to the mix: #5290

Personally I wouldn't be opposed to a function like SDL_GetDisplaySizeInPixels that shows the maximum resolution and ignores all OS scaling - it would address our needs and would allow the other display calls to keep thinking in terms of logical size, which is more appropriate anyhow (the exception being when you enable high-DPI, and at that point you pretty much know what you're getting into when it comes to logical/pixel mismatches).

This also sounds good to me, though I think a function like that should also have a flag or hint to configure whether the returned resolution should include a notch area or not on iPhones/Macs that have them. Right now, there's no easy way to get the best notchless native resolution on a notched Mac in SDL2.

[slouken]

Adding iOS to the mix: #5290
Personally I wouldn't be opposed to a function like SDL_GetDisplaySizeInPixels that shows the maximum resolution and ignores all OS scaling - it would address our needs and would allow the other display calls to keep thinking in terms of logical size, which is more appropriate anyhow (the exception being when you enable high-DPI, and at that point you pretty much know what you're getting into when it comes to logical/pixel mismatches).

This also sounds good to me, though I think a function like that should also have a flag or hint to configure whether the returned resolution should include a notch area or not on iPhones/Macs that have them. Right now, there's no easy way to get the best notchless native resolution on a notched Mac in SDL2.

There is a task to add a separate API for this in #3243

[slime73]

This is fixed in SDL3's recent commits.

[slouken]

FYI, there's a plan to add the notch information as a separate task in #3243.