We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3031

Summary: DPI scaling issues
Product: SDL Reporter: Coriiander <coriiander>
Component: videoAssignee: Sam Lantinga <slouken>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: amaranth72
Version: 2.0.3   
Hardware: All   
OS: Windows 7   

Description Coriiander 2015-06-22 16:32:34 UTC
I am aware there are various bug reports with regards to system that run display scaling (which isn't an uncommon thing). I also filed such a report about characters being chopped off in the custom message box. Anyway, here's yet another one:

On my system, which runs at 150% display scaling, the window size is different in various builds. In the debug build the window shows up smaller (unscaled), in the release build it shows up larger (scaled). I'm not sure what the correct behaviour would be as display scaling is about scaling text, not controls. However, with there being a difference between debug and release builds, there's a bug in SDL.

As mentioned in my other bug report (about message box), I think it would be a good idea if SDL would get the display scaling handled correctly. This would be especially important for touch-enabled devices.

As for code to reproduce, nothing fance. Just a simmple SDL_CreateWindow like 
window = SDL_CreateWindow("test", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 1066, 600, 0);
Comment 1 Coriiander 2015-06-23 03:32:58 UTC
ADDENDUM:

While on the same machine, I don't have access to the previous project(s) anymore. However, in a new project, with a different design, the issue is not present. It is quite likely the reported issue has something to do with the selected runtime libraries.

When reported issue occurs:
The main application links to both SDL2.lib and SDL2main.lib.

When reported issue does not occur:
A DLL, to serve as mid-layer between app + SDL, links to SDL2.lib.
The main application links to that DLL, but not to SDL2main.lib.
Comment 2 Alex Szpakowski 2016-03-19 05:13:03 UTC
Is the intermediary DLL calling SetProcessDpiAwareness / SetProcessDpiAware?
Comment 3 Coriiander 2016-03-19 17:01:27 UTC
(In reply to Alex Szpakowski from comment #2)
> Is the intermediary DLL calling SetProcessDpiAwareness / SetProcessDpiAware?

No, and it shouldn't. Those functions are to be called directly from the main executable only. Anyway, I believe this bug report can be removed. The mistake is not within SDL, but within clients omiting to specify DPI-awareness in their main executable manifest (the way it should be done). With it specified, all is just fine. DLL should remain agnostic as is.
Comment 4 Sam Lantinga 2016-03-20 17:01:25 UTC
Okay, thanks for the update.