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.

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

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

(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.

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?

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.