Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_WINDOW_FULLSCREEN produces off-center 640x480 window on Win 8 with 150% DPI scaling #1628

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

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

Comments on the original bug report:

On 2014-09-02 23:44:47 +0000, Eric Wasylishen wrote:

Summary: Using SDL_WINDOW_FULLSCREEN on a 640x480 window produces an off-center fullscreen window when Windows is set to 150% DPI on a 2880x1800 display.

Tested with http://libsdl.org/tmp/SDL-2.0.4-9121.zip (Sept 2) in MSVC 2013 Express, on windows 8.0.

My display is 2880x1800 pixels (retina MacBook).

Steps to reproduce:

  • Set windows DPI scaling to 150% (right click desktop, screen resolution, "make text and other items larger or smaller", select Larger - 150%, logout and login as prompted)
  • Launch testgl2 included with sdl2
  • Press Ctrl+Enter to enter SDL_WINDOW_FULLSCREEN mode

Expected: spinning cube in the center of the screen
Actual: spinning cube in the lower-right corner of the screen

--

possibly related: https://bugzilla.libsdl.org/show_bug.cgi?id=2328

--

More details:

  • SDL_GetDisplayBounds returns {1921, 1201} (I guess that's the logical size, because 150% of that is 2880x1800)
  • When SDL calls ChangeDisplaySettingsEx, it's requesting a 640x480 fullscreen mode (sounds correct)

On 2014-09-03 00:51:23 +0000, Eric Wasylishen wrote:

Well, one option is calling SetProcessDPIAware to tell the OS not to scale SDL windows, which fixes this. FWIW Microsoft recommends games do that: http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266%28v=vs.85%29.aspx#partial_rendering_of_a_full-screen_application

Also, SFML does that: https://github.com/LaurentGomila/SFML/blob/master/src/SFML/Window/Win32/WindowImplWin32.cpp#L61

Otherwise, the problem is in WIN_SetWindowFullscreen. It calls WIN_GetDisplayBounds(_this, display, &bounds), which returns bounds of 640x480. Then SetWindowFullscreen calls SetWindowPos with (0, 0, 640, 480) but Windows seems to intrepret the 640x480 there as a logical size, scaling it up, resulting in the window being larger than the screen resolution and getting clipped.

On 2015-02-23 04:32:31 +0000, Alex Szpakowski wrote:

Related bug report: https://bugzilla.libsdl.org/show_bug.cgi?id=2328

On 2015-02-24 04:49:05 +0000, Ryan C. Gordon wrote:

*** Bug 2328 has been marked as a duplicate of this bug. ***

On 2015-08-30 17:37:29 +0000, Alex Szpakowski wrote:

(In reply to Eric Wasylishen from comment # 1)

Then SetWindowFullscreen calls SetWindowPos with (0, 0, 640, 480)
but Windows seems to intrepret the 640x480 there as a logical size, scaling
it up, resulting in the window being larger than the screen resolution and
getting clipped.

The documentation for SetWindowPos says the width and height parameters are in real pixels rather than logical units.

I believe this may be the real problem: https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx#partial_rendering_of_a_full-screen_application

Microsoft doesn't recommend a solution other than having the executable declare itself as DPI-aware (and Microsoft strongly recommends against DLLs declaring DPI awareness.)

It seems like Microsoft has designed their high-DPIs in a manner that prevents SDL from making good use of them.

On 2015-09-03 06:55:56 +0000, Eric Wasylishen wrote:

My original test case (the OS set to 150% scaling, Ctrl+Enter in the testgl2 sample, spinning cube is cut off) seems to be fixed under Windows 10. I tried with both SDL2 HG and the SDL-2.0.4-9121.zip build I experienced the bug with last year on Windows 8, so it must have been a bug in Windows 8 that MS fixed in Win10.

I'm not sure if it is possible to fix this on Win8, either. I did spend some time debugging it last year and failed to find any fix we could do in SDL.

We can either close this bug or leave it open to discuss Windows High-DPI stuff.

--

The documentation for SetWindowPos says the width and height parameters are in
real pixels rather than logical units.

That's true, however, if an application doesn't declare itself DPI-aware, I assume all API's that claim to take or return real pixels are actually returning some scaled "virtual pixels".

Microsoft doesn't recommend a solution other than having the executable declare
itself as DPI-aware (and Microsoft strongly recommends against DLLs declaring
DPI awareness.)
It seems like Microsoft has designed their high-DPIs in a manner that prevents
SDL from making good use of them.

Yeah, I noticed the recommendation against DLLs activating DPI-awareness too.

I think SDL could be one of the exceptions where it makes sense, though.
Qt does it, for example, see http://doc.qt.io/qt-5/highdpi.html

I'm thinking the API in SDL should be done as a hint.
We already have SDL_HINT_VIDEO_HIGHDPI_DISABLED, what if there was a SDL_HINT_VIDEO_HIGHDPI_ENABLED? This would be opt-in, you would have to set the hint before initializing SDL video, and if set, SDL would call the relevant Windows API's to enable High-DPI awareness for the application. It would be like passing the SDL_WINDOW_ALLOW_HIGHDPI flag for every window.

If we went this way, it might be good to deprecate the SDL_WINDOW_ALLOW_HIGHDPI flag (since it can't be implemented on windows, afaik) and make SDL_HINT_VIDEO_HIGHDPI_ENABLED the preferred way to opt in to High-DPI support.
Thoughts?

On 2017-07-22 04:02:48 +0000, Eric Wasylishen wrote:

Good news.. I set up a Windows 8 machine today and this is fixed with current HG.

I can still reproduce with http://libsdl.org/tmp/SDL-2.0.4-9121.zip , so it was fixed some time between that .zip file and now.

I'll mark this as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant