RemedyBG»Forums
2 posts
High DPI with scaling options
Edited by tonymarklove on Reason: Initial post
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?
309 posts / 1 project
None
High DPI with scaling options
This may not be what you mean but you can increase both the UI font size and the text font size (independently) from the Window>Style menu.

I don't have a 4k monitor to test on. Let me know if this works okay for you.

Thanks.
2 posts
High DPI with scaling options
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.
309 posts / 1 project
None
High DPI with scaling options
Cool. Thanks for the additional information!
Simon
5 posts
High DPI with scaling options
I'd also really appreciate this feature!
Ryan McQuen
7 posts
High DPI with scaling options
Edited by Ryan McQuen on Reason: Formatting fixes.
@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:

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.
309 posts / 1 project
None
High DPI with scaling options
Will that manifest work on Windows 7/8? The one I'm using currently using looks like:

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.
Ryan McQuen
7 posts
High DPI with scaling options
Edited by Ryan McQuen on
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.
Ryan McQuen
7 posts
High DPI with scaling options
For reference, here is the Microsoft recommended version that never worked for me:

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
Ryan McQuen
7 posts
High DPI with scaling options
Here's the error I get when launching:
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
Ryan McQuen
7 posts
High DPI with scaling options
Edited by Ryan McQuen on
@x13pixels, did you ever try adding the dpiAwareness prop to the manifest of RemedyBG?
309 posts / 1 project
None
High DPI with scaling options
I did not, sorry. Looks like that property is valid for Windows 10 v1607 and later but you can have both properties in a single manifest. I'll make this change in the next release. Thanks for reminding me.
Ryan McQuen
7 posts
High DPI with scaling options
Just saw the update, thanks!
John Chadwick
1 posts
High DPI with scaling options
Edited by John Chadwick on Reason: Added version of RemedyBG observed.
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.