More on Windows and scaling

About a year ago I made a post on windows scaling

So I tried to see if they have fixed stuff the past year – and NO it is actually worse now…

I had hoped the Visual Studio were fixed but it is not. Even if you do as I suggested on how to make a WinForm app Per Monitor DPI Aware See this post, this has to be modified and they still have several issues.

One is that they during design scale down the output with the scale factor of the primary monitor, from what the source files says!!! So if you compile your source on a machine with 200% scaling on the primary monitor, your app during design and after is a quarter in size of what it will be if you compile it on a machine with 100% on the primary monitor!! Did no one really check/fix that VS can not be used with any meaning on a modern laptop for over a year???

And one of the base calls SetProcessDpiAwareness, that should replace the old one SetProcessDPIAware seems to only scale the header now… (The old one works as before though)
so the small helper class I suggested does not work any longer unless you use the old depreciated method….

Even MS own explorer’s Restore previous folder windows at logon messes up with the scaling, if your primary monitor is say 200%, and your secondary is 100%. and the last explorer you worked with is on the primary monitor, they cut the ones on the secondary monitor down to a quarter of their size each time you do a logoff/logon…

(And YES VS also fumbles with the windows-sizes stored when the scale is changed on another monitor, but that is a minor issue…)

They seem to simply have not bothered to test the most basic stuff with anything but the same scale on all monitors.

It is a pity, as the scaling in principle is a good idea, to handle an issue that have good historical reasons (*). And for programs made with the (horribly ugly) flat design, that are vector-based it looks good.

And they are so close to getting the rest right, that I do not understand why they do not do it.

 

One thing I think they should do was to add a setting so that the user could CHOOSE to use the nearest integral setting for legacy apps. So the old apps always appeared sharp with 1×1, 2×2, 3×3,… pixels sized logical pixels. This way they would look no worse that they would have on an old monitor, so jagged: yes, but blurry: no.

Optimally the scaling would be allowed on a per app basis so it was a on the compatibility tab of the properties, along the already existing “Override high DPI scaling behaviour

Another thing they could (easily) do, to handle the real old stuff, would be to add an (integer!) scaling factor to HyperV. So if you have an ancient 16 bit program made to be used in pure text or 640×480, most likely a fact 200%, 300% or even 400%, might be great on a high resolution monitor.

 

(*) when windows was introduced they worked in pixes not vectors, simply because the needed calculation powers to do the vector-graphics was not there then. This is LOOOONG before fancy graphics cards. And as MS has been really good with keeping backwards compatibility, they still work in pixel. And for some reason they do not do much to make VS ease the transition to DPI-aware apps.