Use Per Monitor Aware instead of System Aware for DPI scaling on Windows#2268
Merged
Conversation
Member
|
I think new features like this ought to target the |
Member
|
Note that the forum discussion goes beyond this PR (and targets It's somewhere between a bugfix and a feature. The current behavior can easily be seen as broken, thus it becoming a bug. At the same time you can also argue that it's a change in behavior, thus it being a feature. |
eXpl0it3r
approved these changes
Nov 6, 2022
Member
|
Thanks for this enhancement! I'll get back to the forum thread as soon as possible 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
As mentioned in my recent forum post, I believe SFML should enable Per Monitor Aware instead of System Aware DPI scaling on Windows.
I know that SFML 2.6 doesn't support high-DPI scaling yet nor has proper support for multiple monitors, but by calling
SetProcessDpiAwareness(PROCESS_SYSTEM_DPI_AWARE)before creating the window it has been forcing a non-optimal behavior which can easily be improved.Old behavior
When an 800x600 window is requested, SFML creates an 800x600 window irrelevant of the DPI scaling of the monitor.
When changing the DPI of the monitor while the application is running, or when moving the window to a monitor with a different scale factor, Windows stretches the window however. The example code will keep printing "800x600" in the command line, but the real window size will be different. Everything still worked, but all rendering is being stretched by Windows.
New behavior
Nothing changes on window creation, you still get an 800x600 window irrelevant of the DPI scaling of the monitor.
When changing the DPI of the monitor while the application is running, or when moving the window to a monitor with a different scale factor, the window now keeps it 800x600 size with a 1:1 mapping between window coordinates and pixels.
Per Monitor awareness was added with Windows 8.1, which is the same version where SetProcessDpiAwareness was introduced (which was already used to set DPI awareness), so this change keeps all Windows versions supported. I thus see no downsides to this new behavior.
How to test this PR?
The following code will create a window and print "800x600" in the command line the whole time.
You can change the scaling factor in Windows in the Display settings to something other than "100%" to see the behavior described above. What is printed in the command line never changes, but without the change from this PR, the window size would visually change.