You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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:
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.
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.
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:
On 2014-09-03 00:51:23 +0000, Eric Wasylishen wrote:
On 2015-02-23 04:32:31 +0000, Alex Szpakowski wrote:
On 2015-02-24 04:49:05 +0000, Ryan C. Gordon wrote:
On 2015-08-30 17:37:29 +0000, Alex Szpakowski wrote:
On 2015-09-03 06:55:56 +0000, Eric Wasylishen wrote:
On 2017-07-22 04:02:48 +0000, Eric Wasylishen wrote:
The text was updated successfully, but these errors were encountered: