Very blurry with screen scaling

[eugenesvk]

Both icons and text look blurry at 150% scaling

[german-one]

@stianhoiland I could jump in here if you like. There are two possibilities:

• Microsoft wants us to specify DPI awareness and context in the manifest. Creating a manifest file and adding it in the resource script is easy. However, it requires you to turn off automatic manifest creation in the linker settings of MS Visual Studio.
• Alternatively, we could call SetThreadDpiAwarenessContext() (min. Windows 10) or one of its ancestors if you want to keep some backward compatibility.

Do you have any preference?

[stianhoiland]

@eugenesvk Nice catch. This is something cmdtab should support.

@german-one Thanks for the offer of assistance and quick summary! My eyes are crossing over trying to wrap my head around the various DPI-related APIs. Here are the right docs, and this seems to be a very complete reference implementation, though all too verbose and extensive for my liking—I like small surfaces :)

I can't shoulder this change at the moment. I will however review any pull requests for this feature. In particular, since cmdtab is such a long-running process, its implementation should support WM_DPICHANGED.

EDIT: It is hard for me to state a preference since I can't visualize the overall impact of the alternatives. I may prefer the manifest solution if it is the original DPI awareness mechanism. What's the significance of requiring that automatic manifest creation be turned off?

[german-one]

[...] its implementation should support WM_DPICHANGED.

I really don't think that you want to process the WM_DPICHANGED message. Let me try to explain it a little more in detail ...
The reason for making this app DPI aware is that we want antialiasing for the window content getting calculated based on the actual DPI and scaling, rather than on an assumption it was 96 DPI with 100% scaling. Once this is specified, it will keep working accordingly. You only process WM_DPICHANGED if you want the app doing something if the DPI value changed. Perhaps something like updating the size of the window. However, this would feel quite wrong and could have been specified from the beginning. E.g. making the app per-monitor DPI aware would be simply another possible setting via manifest or API. But - as I said - it feels wrong if the window gets a completely different size whenever you move it from one monitor to another.
So, out of my experience, it is absolutely sufficient to set it system DPI aware.

---

[...] I may prefer the manifest solution if it is the original DPI awareness mechanism. [...]

Well, this is rather Microsoft's preference. They may have a reason 🤷‍♂️ The manifest file would look like so ...

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">system</dpiAwareness>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

... and get added to the resource script like this ...

1 RT_MANIFEST "cmdtab.manifest"

[...] What's the significance of requiring that automatic manifest creation be turned off?

Otherwise there would be two manifest files which makes the linker throw because it can handle only one.

---

Only for completeness and in case you change your mind - we can get the same effect by just calling one of the below API. Preferably after the AlreadyRunning clause in RunCmdTab().

SetProcessDPIAware() (>= Vista)
SetProcessDpiAwareness(PROCESS_SYSTEM_DPI_AWARE) (>= Win 8.1)
SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_SYSTEM_AWARE) (>= Win 10)

[stianhoiland]

v1.6 (0da13fd) now implements a manifest file with DPI entries. No other accommodations for scaling (margins, font size, etc.) have been made yet. I'm keeping this issue open until such adjustments have been made or deemed unnecessary. Download the newest version here.

[dubeg]

In 1.6.2, the manifest (is it embedded?) doesn't seem to make a difference. It still looks a bit blurry.

[stianhoiland]

Thanks for checking.

I'm rather certain the manifest is getting embedded because I'm getting updated visual styles after compiling with mingw-w64, which skips MSVC's #pragmas which would have been the only other way I'd be getting updated visual styles.

Are we sure this is a DPI issue? Check text and window dimensions. You see, getting app icons is a really weird thing on Windows, and there's no guarantee that apps have any size icons to use in the switcher. cmdtab is just doing a best effort thing. So it may be a resource issue, as in, the app(s) don't have high resolution icons for cmdtab to use.

[stianhoiland]

I tried to use 150% scaling myself. It doesn't look right...

[dubeg]

Hmm. This one seems to show icons quite OK: https://github.com/hdlx/AltAppSwitcher

[stianhoiland]

Fixed in a1d7f0e. If someone knows exactly why, please explain :)

[stianhoiland]

Proper DPI scaling support added in a7972f9. Finally closing this now :) Keep an eye out for the next release.

[german-one]

If someone knows exactly why, please explain :)

xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" adds the asmv3 namespace to the manifest. This is required, while repeating it like in <asmv3:application> might not be needed as long as this doesn't make the element ambiguous. (I didn't test with only <application> and friends though.)

[stianhoiland]

a254ea4 introduces dynamic DPI scaling. cmdtab now responds to changing the scaling percentage in Windows' Settings without having to relaunch (a windows switcher can't afford such a luxury!). I have architected things such that cmdtab can be displayed not just on multiple monitors, but multiple monitors with differing DPI scaling. It remains to be tested though, since I don't have multiple monitors. I'm reopening this issue until this functionality has been determined to work correctly. If you have multiple monitors, please do a checkout, test it and let me know!

[stianhoiland]

It was a mess to figure this DPI stuff out. At the moment there is a known bug in that the name/title text doesn't scale. I haven't seen a nice way to call GetStockObject(DEFAULT_GUI_FONT) (line 1167) in a way that yields a scaled font, and manually handling it is ugly (though possibly necessary in the end).

I think the issue is that I'm circumventing how Windows is keeping track of the DPI state of the cmdtab process or window. I'm not working with the DPI that Windows reports for the cmdtab switcher window (the recommended GetDpiForWindow API), but instead the DPI of the monitor with the mouse cursor (the older GetDpiForMonitor) and manually scaling off of that. This is to avoid having to invisibly move the cmdtab window around to other monitors as the cursor moves between monitors. If I did that, then I think Windows would report the correct DPI for the switcher window and give me a scaled font for DEFAULT_GUI_FONT. But instead Windows is giving cmdtab the scaling value of the last monitor it was displayed on (and a font that suits that monitor), and not the monitor it's about to pop up on.