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 - DPI scaling issues
Summary: DPI scaling issues
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.3
Hardware: All Windows 7
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-22 16:32 UTC by Coriiander
Modified: 2016-03-20 17:01 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.