Developer Reference Windows DPI

Changes to how Windows handles DPI settings

Have you noticed that many applications look a little fuzzy recently?  If so, my guess is that you've used "Customise your display" so that the size of text, apps and other items is greater than 100%.

Windows 10 is particularly inconsistent in this regard - the windows of many for the built-in applications just look awful unless you've set the slider to 100%.  Here's the Services window from my PC where I've set the custom size to 120%.  Notice that the text in the title bar is rendered fine, but within the client area of the application it's not so good.

What's wrong?  Well the Microsoft Management Console hasn't been declared DPI aware.  When you change the custom size percentage, you're actually changing what DPI might be reported to the applications.

Using the Process Explorer from www.sysinternals.com you can see which applications you have running have been marked as DPI aware.

There are 3 levels of DPI awareness for applications in Windows.

  • Not aware - the DPI reported to the application is 96 DPI regardless of the user's preferences.
  • System aware - the DPI reported to the application is that set by the user. On systems with multi-monitors, it's the DPI from the monitor designated as the main display.
  • Per monitor aware - the DPI reported to the application is that set by the user for the monitor that the application window mostly occupies.

There's a detailed article about all of this on MSDN but clearly Microsoft hasn't applied this to everything they do yet.

That's not quite the full story however, because what this article doesn't tell you is that the default behaviour, at least on Windows 8.1, appears to have recently been changed.

Before we release a new version of ENCX, we perform an automated set of tests.  Some of those tests generate bitmap files and we compare those with what the last release produced.  On investigation, we noticed that the DPI of those bitmaps had changed.  After some head scratching and running the tests on different machines and configurations, we re-ran the tests generated from and using the old version of ENCX.  The results were a bit alarming - the bitmaps now had a different DPI from the last time we ran the tests in March!

So the only conclusion we could draw is that a Windows Update had changed how DPI is reported to applications, at least on Window 8.1.  I guess this may have been done because Microsoft had made a change in Windows 10 and they wanted to retro-fit this change to Windows 8.1 to make them both behave the same.

So the new default behaviour for .Net applications now appears to be "not aware", so drawing is always done using 96 DPI.  Previously the default behaviour appears to have been "System aware".  Therefore to "fix" this, when we released version 2.2.0.130 of ENCX, we added manifest files to some of the sample projects just so that these applications declared themselves DPI aware.  It does improve the look of things.  Compare these two screenshots taken from a machine using 120%.

Not DPI Aware

DPI Aware

To be more exact, the manifests we've added to the samples actually declare the applications as DPI per monitor aware.  This gives a much better result than system aware if you have displays with different DPI settings (e.g. a Microsoft Surface connected to an external monitor).

If you only ever use 100% scaling in Customise your display, then none of this affects you. However, you'll also need to tell your customers to not change this setting too!