I run Windows on a 4k montior with 200% scaling enabled. It appears that RemedyBG respects the 4k resolution but not the scaling factor set in Windows. Is that the current state of things, or am I missing an option somewhere?
Edited by tonymarklove
on
Reason: Initial post
Yes that does work resonably well. I don't think every UI element is scaled perfectly but it is certainly usable. Thanks.
If you want to look into supporting scaling in Windows in the future, take a look at the GetDpiForWindow function. The default return value for an unscaled screen is 96. On my system, I've gone into the display settings in Windows and selected 200% scaling, and the return value is 192. So you effectively get a scaling factor (192/96 = 2) for displaying all UI elements.
I've done this myself with ImGui, so it's definitely possible with a bit of care when passing coordinates to ImGui.
If you want to look into supporting scaling in Windows in the future, take a look at the GetDpiForWindow function. The default return value for an unscaled screen is 96. On my system, I've gone into the display settings in Windows and selected 200% scaling, and the return value is 192. So you effectively get a scaling factor (192/96 = 2) for displaying all UI elements.
I've done this myself with ImGui, so it's definitely possible with a bit of care when passing coordinates to ImGui.
@x13pixels, I ran into a similar issue on my project, I found that using a Manifest file embedded with mt.exe was a lot easier and cleaner than handling DPI programmatically.
https://github.com/ryanpcmcquen/b...b6f38ede3/windows/basque.manifest
https://github.com/ryanpcmcquen/b...3b67baed12ab6f38ede3/Makefile#L12
@tonymarklove, you should be able to use that Manifest with little to no modifications and add it to Remedy's .exe like so:
If that works it should be easy enough for x13pixels to add that to the project for the next release.
https://github.com/ryanpcmcquen/b...b6f38ede3/windows/basque.manifest
https://github.com/ryanpcmcquen/b...3b67baed12ab6f38ede3/Makefile#L12
@tonymarklove, you should be able to use that Manifest with little to no modifications and add it to Remedy's .exe like so:
1 | mt.exe -nologo -manifest remedybg.manifest -outputresource:remedybg.exe |
If that works it should be easy enough for x13pixels to add that to the project for the next release.
Edited by Ryan McQuen
on
Reason: Formatting fixes.
Will that manifest work on Windows 7/8? The one I'm using currently using looks like:
This is embedded in remedybg.exe using the flags "/manifest:embed" and "/manifestinput:filename.manifest".
Thanks.
1 2 3 4 5 6 7 8 | <?xml version="1.0" encoding="utf-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware> </windowsSettings> </application> </assembly> |
This is embedded in remedybg.exe using the flags "/manifest:embed" and "/manifestinput:filename.manifest".
Thanks.
You'll have to test it, I don't have access to either of those enviros. According to Microsoft's docs (as far as I can tell), you can have a dpiAware setting and a dpiAwareness setting, but I got errors when implementing both. Your mileage may vary. Maybe it was because I didn't have an xmlns prop specified.
Edited by Ryan McQuen
on
For reference, here is the Microsoft recommended version that never worked for me:
I'll give it another spin with that 2005 xmlns prop.
Reference:
https://docs.microsoft.com/en-us/...ess-with-the-application-manifest
1 2 3 4 5 6 7 8 9 | <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness> <dpiAware>true</dpiAware> </windowsSettings> </application> </assembly> |
I'll give it another spin with that 2005 xmlns prop.
Reference:
https://docs.microsoft.com/en-us/...ess-with-the-application-manifest
Here's the error I get when launching:
Adding that xmlns prop fixes it though. Thanks @x13pixels!
https://github.com/ryanpcmcquen/b...62753c84b2b0dd32ad6595b969e315f69
1 | The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. |
Adding that xmlns prop fixes it though. Thanks @x13pixels!
https://github.com/ryanpcmcquen/b...62753c84b2b0dd32ad6595b969e315f69
@x13pixels, did you ever try adding the dpiAwareness prop to the manifest of RemedyBG?
Edited by Ryan McQuen
on
Just saw the update, thanks!
It would be great to see proper high DPI support in RemedyBG, but I think there's some misunderstanding here, either on my end or otherwise.
Currently, I'm looking at RemedyBG 0.3.0.7 running locally. It displays correctly on displays that are 1.0 scaling, but it looks small on displays that are >1.0 scaling. On one hand, this suggests that the program is being treated as DPI Aware in Windows, but also, it is probably undesirable, because RemedyBG does not appear to react in response to different DPIs. Most likely, it would be a better experience if RemedyBG explicitly set the DPI Awareness context to Unaware. This will result in the system handling upscaling and downscaling, which means the UI will look blurrier, but will render correctly. I suppose there may be differing preferences, but it is always possible to override the application using compatibility settings if someone wanted to do that.
"Correctly" handling high DPI, in my opinion, would entail ensuring that everything renders at the correct scale factor lower in the pipeline than user preferences, so that the same font size will look the same size across different monitors. Undoubtedly this would require additional graphics refactoring work and I doubt it is a priority, but I think to implement DPI correctly this would be the ideal direction to go in. For use cases like mine where I have monitors at different DPIs connected (like in a typical laptop docking scenario) changing the settings all the time to accomplish this would be unideal and in some cases less usable than DPI unaware (because with DPI unaware, Windows 10 will handle upscaling on a per-monitor basis, dynamically.)
Per Monitor V2 is the API you ideally want to use, as it updates a whole ton of Windows behaviors to be more reasonable. The only downside is that it is only supported on new-ish Windows 10 versions, but at least for earlier versions of Windows you could fall back to Per Monitor V1 or even DPI-unaware with relative ease. Implementing it is reasonably simple:
1. Set the relevant manifest flags or call user32.SetProcessDpiAwarenessContext (more on that later.)
2. After creating the window, call user32.GetDpiForWindow to get the initial DPI value.
3. Listen for WM_DPICHANGED. When you get WM_DPICHANGED, you would probably to adjust the scaling factor for that window and then call SetWindowPos with the suggested window size (sent via lParam as an LPRECT.)
BTW, it is not strictly necessary to use a manifest to tell the system what DPI scaling mode to use. You can also set it at runtime using user32.SetProcessDpiAwarenessContext since Windows 10 1703, which may be useful in case of setting newer scaling modes such as Per Monitor V2 that are only available in newer versions of Windows 10 anyways.
P.S.: There is some information 'round the web about DPI scaling and Dear Imgui, although I have no idea how much of it would be useful or relevant to RemedyBG.
Once again, I understand that this is not likely to be a priority. I'm dumping this here because I personally have a bit of experience working with Windows DPI scaling and found it difficult to figure out how exactly to handle it correctly. Hopefully this helps if there is ever a desire to do more advanced DPI scaling support.
Currently, I'm looking at RemedyBG 0.3.0.7 running locally. It displays correctly on displays that are 1.0 scaling, but it looks small on displays that are >1.0 scaling. On one hand, this suggests that the program is being treated as DPI Aware in Windows, but also, it is probably undesirable, because RemedyBG does not appear to react in response to different DPIs. Most likely, it would be a better experience if RemedyBG explicitly set the DPI Awareness context to Unaware. This will result in the system handling upscaling and downscaling, which means the UI will look blurrier, but will render correctly. I suppose there may be differing preferences, but it is always possible to override the application using compatibility settings if someone wanted to do that.
"Correctly" handling high DPI, in my opinion, would entail ensuring that everything renders at the correct scale factor lower in the pipeline than user preferences, so that the same font size will look the same size across different monitors. Undoubtedly this would require additional graphics refactoring work and I doubt it is a priority, but I think to implement DPI correctly this would be the ideal direction to go in. For use cases like mine where I have monitors at different DPIs connected (like in a typical laptop docking scenario) changing the settings all the time to accomplish this would be unideal and in some cases less usable than DPI unaware (because with DPI unaware, Windows 10 will handle upscaling on a per-monitor basis, dynamically.)
Per Monitor V2 is the API you ideally want to use, as it updates a whole ton of Windows behaviors to be more reasonable. The only downside is that it is only supported on new-ish Windows 10 versions, but at least for earlier versions of Windows you could fall back to Per Monitor V1 or even DPI-unaware with relative ease. Implementing it is reasonably simple:
1. Set the relevant manifest flags or call user32.SetProcessDpiAwarenessContext (more on that later.)
2. After creating the window, call user32.GetDpiForWindow to get the initial DPI value.
3. Listen for WM_DPICHANGED. When you get WM_DPICHANGED, you would probably to adjust the scaling factor for that window and then call SetWindowPos with the suggested window size (sent via lParam as an LPRECT.)
BTW, it is not strictly necessary to use a manifest to tell the system what DPI scaling mode to use. You can also set it at runtime using user32.SetProcessDpiAwarenessContext since Windows 10 1703, which may be useful in case of setting newer scaling modes such as Per Monitor V2 that are only available in newer versions of Windows 10 anyways.
P.S.: There is some information 'round the web about DPI scaling and Dear Imgui, although I have no idea how much of it would be useful or relevant to RemedyBG.
Once again, I understand that this is not likely to be a priority. I'm dumping this here because I personally have a bit of experience working with Windows DPI scaling and found it difficult to figure out how exactly to handle it correctly. Hopefully this helps if there is ever a desire to do more advanced DPI scaling support.
Edited by John Chadwick
on
Reason: Added version of RemedyBG observed.