Show Posts
1
SFML development / Re: DPI-Scaling on Windows
« on: November 27, 2023, 08:06:30 pm »
I have no idea how things will work with child windows or windows that weren't created with SFML, so I won't comment on that.
The thing that needs to be discussed is how much options are left to the user. Will SFML force a certain scaling or will it provide many different options. I'll list the possible options that I'm aware of below.
1) DPI-Unaware
When using this, Windows will scale the entire window, including the title bar. Windows does everything for you and the developer doesn't has to do anything. The big downside is that the whole window will be blurry, making text less nice to read.
This mode is really intended for legacy applications that were written without DPI in mind.
2) Don't scaling anything (Per Monitor Aware V1 without handling WM_DPICHANGED)
This is what we currently do in SFML 2.6 and what my PR does if you don't set the highDpi flag.
Both the window contents and the title bar are unscaled and show up as if the monitor had 100% scaling. The window will look too small for people that have DPI scaling on their monitor. While that clearly isn't an ideal thing to do, it gives all the control to the developer. The window has exactly the amount of pixels that the developer wanted, without SFML manipulating anything.
The problem with this method is mainly that SFML doesn't provide enough tools to the developer to actually do anything themself. They would need to know the DPI scaling of each monitor, and get an event when the window switches monitor. Only then would they be able to manually decide what the wanted window size should be.
3) Scaling everything automatically (Per Monitor Aware V2)
This is what my PR does with the highDpi flag.
The advantage is that SFML takes care of all the DPI changes for the user, the downside is that it takes all control away from the user.
I'm sure there are alternative ways to implement this, but this was the easiest that I could think of: only manipulating the window size on window creation and on DPI changes (e.g. when switching monitor). When a window of 800x600 is requested on a monitor with 200% scaling, a window of size 1600x1200 will be created instead.
While SFML doesn't has to do the same as SDL or GLFW, it might be useful to know how they handle things:
- SDL uses option 1 (DPI-Unaware) as default. When a high-DPI flag is set, they act similar to option 3 (scaling contents and title bar automatically). The big difference with my implementation is that SDL chose to keep the window size and mouse events unscaled. So even with the high-DPI flag set, the real window size and rendering area are larger than what SDL_GetWindowSize reports, and you have to manually scale mouse events to figure out where on the render target the mouse is located.
- GLFW uses option 2 (not scaling anything) and option 3 (scaling contents and title bar automatically) based on a global flag. My PR code was heavily influenced by this design, because I liked how it kept the window and rendering area the same unlike with SDL.
With scaling options 1 and 3 above, the contents and decoration are scaled the same. For option 2, you could provide an alternative that would not scale the contents but would scale the title bar. So that gives a 4th scaling option:
4) Scaling only title bar (Per Monitor Aware V2 while keeping the window at a fixed size)
I'm not sure how easy or difficult this is to implement, I do know it requires handling WM_DPICHANGED. When moving monitor, Windows won't resize the window. So when it changes the title bar size, it also changes the client size of the window (which you wouldn't want). So you would need to implement WM_DPICHANGED in such a way that it reverts the change that Windows automatically makes (this will likely be similar to the code from option 3).
With all 4 scaling modes mentioned above (at least when implementing it like I did in the PR), the window size and rendering area are the exact same, so no additional functions are needed. The size of the window on screen is also the size reported when requesting the window size in SFML.
The only case where the scaled and unscaled sizes differ is with "DPI-Unaware", but there Windows is intentionally providing SFML with the wrong window size, so as far as SFML can tell the rendering size is still the same as the window size (and Windows will just stretch it when displaying).
One thing that needs to be done is make people aware that the window size will no longer be what they specify in the API. That's why I had the highDpi flag: to keep thing as expected until the user made the choice to activate the new behavior. But if the other scaling modes are deemed as unneeded, then you could just force the behavior on everyone in SFML 3 without the flag. Although I can think of at least one case where you might want to have such flag (to turn scaling off): what if the user queries the monitor size and tries to create a window that matches it? SFML shouldn't change the window scale at that moment.
Quote
Scaling behavior of the window content
The thing that needs to be discussed is how much options are left to the user. Will SFML force a certain scaling or will it provide many different options. I'll list the possible options that I'm aware of below.
1) DPI-Unaware
When using this, Windows will scale the entire window, including the title bar. Windows does everything for you and the developer doesn't has to do anything. The big downside is that the whole window will be blurry, making text less nice to read.
This mode is really intended for legacy applications that were written without DPI in mind.
2) Don't scaling anything (Per Monitor Aware V1 without handling WM_DPICHANGED)
This is what we currently do in SFML 2.6 and what my PR does if you don't set the highDpi flag.
Both the window contents and the title bar are unscaled and show up as if the monitor had 100% scaling. The window will look too small for people that have DPI scaling on their monitor. While that clearly isn't an ideal thing to do, it gives all the control to the developer. The window has exactly the amount of pixels that the developer wanted, without SFML manipulating anything.
The problem with this method is mainly that SFML doesn't provide enough tools to the developer to actually do anything themself. They would need to know the DPI scaling of each monitor, and get an event when the window switches monitor. Only then would they be able to manually decide what the wanted window size should be.
3) Scaling everything automatically (Per Monitor Aware V2)
This is what my PR does with the highDpi flag.
The advantage is that SFML takes care of all the DPI changes for the user, the downside is that it takes all control away from the user.
I'm sure there are alternative ways to implement this, but this was the easiest that I could think of: only manipulating the window size on window creation and on DPI changes (e.g. when switching monitor). When a window of 800x600 is requested on a monitor with 200% scaling, a window of size 1600x1200 will be created instead.
While SFML doesn't has to do the same as SDL or GLFW, it might be useful to know how they handle things:
- SDL uses option 1 (DPI-Unaware) as default. When a high-DPI flag is set, they act similar to option 3 (scaling contents and title bar automatically). The big difference with my implementation is that SDL chose to keep the window size and mouse events unscaled. So even with the high-DPI flag set, the real window size and rendering area are larger than what SDL_GetWindowSize reports, and you have to manually scale mouse events to figure out where on the render target the mouse is located.
- GLFW uses option 2 (not scaling anything) and option 3 (scaling contents and title bar automatically) based on a global flag. My PR code was heavily influenced by this design, because I liked how it kept the window and rendering area the same unlike with SDL.
Quote
Scaling behavior of the window decoration
With scaling options 1 and 3 above, the contents and decoration are scaled the same. For option 2, you could provide an alternative that would not scale the contents but would scale the title bar. So that gives a 4th scaling option:
4) Scaling only title bar (Per Monitor Aware V2 while keeping the window at a fixed size)
I'm not sure how easy or difficult this is to implement, I do know it requires handling WM_DPICHANGED. When moving monitor, Windows won't resize the window. So when it changes the title bar size, it also changes the client size of the window (which you wouldn't want). So you would need to implement WM_DPICHANGED in such a way that it reverts the change that Windows automatically makes (this will likely be similar to the code from option 3).
Quote
API to get the scaled and unscaled sizes
With all 4 scaling modes mentioned above (at least when implementing it like I did in the PR), the window size and rendering area are the exact same, so no additional functions are needed. The size of the window on screen is also the size reported when requesting the window size in SFML.
The only case where the scaled and unscaled sizes differ is with "DPI-Unaware", but there Windows is intentionally providing SFML with the wrong window size, so as far as SFML can tell the rendering size is still the same as the window size (and Windows will just stretch it when displaying).
One thing that needs to be done is make people aware that the window size will no longer be what they specify in the API. That's why I had the highDpi flag: to keep thing as expected until the user made the choice to activate the new behavior. But if the other scaling modes are deemed as unneeded, then you could just force the behavior on everyone in SFML 3 without the flag. Although I can think of at least one case where you might want to have such flag (to turn scaling off): what if the user queries the monitor size and tries to create a window that matches it? SFML shouldn't change the window scale at that moment.