Blurry display when scaled (because of main window resizing) -- workaround

[Dirge]

Free42 for Windows 10/11: Blurry display when scaled (because of main window resizing), and blurry menu fonts at any scale, whether the main window is resized or not.

Display blurriness showed up when resizing was introduced with release 3.1.4d; it was mitigated somewhat with release 3.1.5b, but the display is still distractingly blurry when the Free42 main window is resized. Menu font blurriness has been a problem since Windows changed its display DPI scaling method many years ago. Here’s a workaround that will not only get rid of display blurriness when resizing, but it will get rid of menu font blurriness as well:

> go to the Free42 program folder
> right-click on the Free42 executable (either Free42Decimal.exe or Free42Binary.exe, whichever you use)
> left-click Properties
> left-click Compatibility tab
> left-click change high DPI settings
> left-click High DPI scaling override
> select Override high DPI scaling behavior.
> Scaling performed by: select Application
> left-click OK > Apply > OK to save changes

Free42’s display and menu fonts should now appear blur-free at any main window size. Associated pop-up dialogs (the About and Preferences dialogs, for example) will also be blur-free, but the dialog windows themselves (which are not resizable) may appear smaller than usual if you use a Windows Display Scale setting greater than 100% -- most Windows 10/11 laptops with 15.6" Full HD displays are set to 125% by default, to cite a common configuration. [Because scaling is now performed by the application rather than by the Windows OS, Free42 will ignore the Windows Display Scale setting and assume a value of 100%.]

* * *

HP laptop with AMD Ryzen 5 5500U & Radeon Graphics

15.6" Full HD display (~141 dpi) 

Windows 11 23H2 with Display Scale setting of 150%

[Thomas Okken]

I don't think I understand the problem. Here are two screen shots of Free42, both with the "Original" skin (chosen because it's small and black and white), once at its natural size and once enlarged by about 50%:

The title bar and menu fonts look the same in both screen shots. The skin is blurrier in the enlarged version, which is inevitable because of how bitmap scaling works; the display is also blurrier in the enlarged version, which is because the tricks I use to keep the display sharp when scaled in the versions for other operating systems don't work in Windows (this is something I still want to improve, but it's going to be a bit complicated).

[Dirge]

Below are two screen shots of Free42 resized/enlarged to the same screen size: the first uses the original/default settings; the second uses the workaround settings. As you can see, the workaround settings produce a notably sharper/crisper digital display image (X: 141.21  Y: 96.00), and button text is a bit sharper/crisper as well. The workaround settings appear to treat Menu fonts (File  Edit  Skin  Help) as scalable/vector fonts rather than as bitmap images, and they resize without blur or distortion as a result. I use the Realistic skin rather than the Standard skin, but the results are comparable. [I’m using a monitor with a fairly high pixel density, 141 PPI, so blurriness may be more pronounced than on a monitor with a low pixel density.]

I hope this clarifies matters.

[Thomas Okken]

Interesting. I'll see if I can reproduce this on my own machine. I use a MacBook Air M1, which has a 2560x1600 screen, so it sounds like I should be able to reproduce those artifacts. (Although the system seems to think it's actually 2880x1800... weird.)

One question: What are the pixel dimensions of your monitor, and what do you have the display scale set to?

[Thomas Okken]

I'm creating an issue to keep track of this: https://codeberg.org/thomasokken/free42/issues/81

[Dirge]

My monitor is Full HD (1920x1080), and Windows 11 display scale is set to 150%.

For troubleshooting purposes, I just set Windows 11 display scale to 125% and then to 100%: the resizing blurriness is about half as noticeable at 125% and not noticeable at 100%. Apparently, Windows display scale is to blame. This makes sense, as the workaround settings essentially tell Free42 to ignore the Windows display scale setting and act as if it’s set to 100%. Unfortunately, many of my apps/programs have unusably small GUI elements if I set Windows display scale to 100%, so I’m forced to use 125% or 150%.

My workaround only applies, then, to Windows users who have Windows display scale set to something other than 100%. I imagine that the Mac OS has a much better high DPI scaling solution than the Windows OS.

[Thomas Okken]

The issue appears to be that Free42 is "DPI unaware," which means it does not respond to changes in display scale. This means that it always renders its windows at the same resolution, and the OS uses bitmap stretching to scale it per whatever display scale happens to be in effect. This secondary scaling partially defeats the logic in Free42 that is supposed to keep the display sharp when scaled, and it introduces some extra blurriness in the skin, and in the parts of the UI that are drawn by the OS.

It is possible to make the app DPI-aware, but it's probably not going to be trivial. I don't actually know what the situation is in other operating systems; I use 100% scaling everywhere so I wouldn't notice scaling artifacts myself. Also, those other platforms mostly support resolution independent UIs out of the box anyway, so the two-step process of rendering and then scaling doesn't happen there. I assume Windows works that way by default because classic Win32 UI layouts tend to react poorly to being rendered at different resolutions, because the changes in relative font metrics, margins, etc. were never taken into account in those designs.

[Dirge]

Thanks for all the info. 

Fortunately, the workaround for Free42 works more or less perfectly for my particular situation, so don’t initiate a painstaking rewrite of Free42 to make it "DPI-aware" on my account.

[Thomas Okken]

I'm somewhat hopeful that the issue can be resolved without writing lots of new code. After all, the contents of the main window are already resizable, that being the whole point of the changes in 3.1.4.* and 3.1.5.*. It sounds like most of what's needed is to simply give permission to Windows to render the app at different scales.

The print-out window may have its problems, and generally speaking, these things are often trickier than they seem at first glance, but I think it'll be worth the effort. I myself have often noticed that the Free42 UI looks a bit clunky compared to other apps (on Windows), but it never occurred to me that scaling might be the issue. Which is a bit silly, because if you take a close look at those screen shots and notice how much better the text in the title bar looks compared to the menu bar, it's actually kind of obvious what's going on, particularly on a modern laptop with a high-DPI display.

And now that I know that it looks even worse with display scales > 100%, I have some pretty strong motivation to address this. Display scaling is a major usability feature, and that's not something I want to ignore.

[Thomas Okken]

Project -> Properties -> Configuration Properties -> Manifest Tool -> Input and Output -> DPI Awareness : High DPI Aware

With just that one change (and a couple of lines of code to scale the skin by 2x to compensate for my Display Scale setting of 200%), it went from this:

to this:

You can see that the menu font and the app icon look much better in the dpi-aware version.

The skin and display actually look blurrier in the dpi-aware version. With the dpi-unaware version, where Windows scales everything up, the scaling is clearly done using pixel doubling without any smoothing, which it can do because my display scale is set to 200%. The dpi-aware version scales up the skin and display itself, and that is subject to the usual smoothing. For the skin, that's just how it is; for the display, that will get fixed once I implement better display scaling, as I mentioned in an earlier post in this thread.

Here's the dpi-unaware version of the Preferences dialog:

compared to the dpi-aware version:

There's still a lot of details to sort out, but I think this looks promising so far.

I won't be able to work on this during the coming week, but I'll definitely pick this up again after that.