Troubleshooting DPI Virtualization and DPI-aware applications, in Windows Vista and Windows 7

Question

I have a problem where an application (written in Delphi) is behaving properly at default 96 DPI settings on all systems, but is behaving inconsistently at the "150% text size" (internally 144 dpi) setting, on different systems. It seems that on some systems, that certain text/font parts of my application are being stretched and on other systems, they aren't. I would have thought that my application, on a certain version of Windows (Win7), at a certain DPI, should behave the same way.

Either my application will make it known to Windows that it doesn't need the DPI Virtualization feature, or it will not. That much I understand. What I don't understand is how DPI changes can cause different appearance on two machines, both running Windows 7, both at 144 dpi, displaying the same fonts and forms at the same fixed sizes.

Is there some configuration-dependant elements involved in DPI Virtualization that I need to inspect in windows (registry etc)? Otherwise, how do you troubleshoot and know whether DPI virtualization is being done on your client window?

In Delphi, one has to set the TForm.Scaled property to false, if one doesn't want scaling. But what I don't understand is that when the main form's Scaled property is true, I cannot always predict the outcome.

What is most perplexing to me in my application, is that I have a control that only misbehaves in my large real application, but which does not misbehave in a standalone app where I am trying to debug just the control. To understand the control behaviour in a standalone app I was forced to make a demo app where I force the DPI awareness in via the manifest file. Then I can reproduce the control drawing glitch, although in a different form.

Here is the manifest file I use in my demo app, which exposes the problems that my controls have with dealing with high-dpi settings in windows. However, one strange thing I have found is that it is possible for an application

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
 <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <asmv3:windowsSettings
         xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
  <assemblyIdentity version="14.0.3615.26342" processorArchitecture="*"            
   name="TestProject" type="win32"></assemblyIdentity>
  <description>High DPI Controls Test App</description>
</assembly>

here's an example of one of about 30 places where the controls in my application are messed up when I disable DPI virtualization in my app. This particular glitch was solved by turning off the Scaled property in my form. But in other places, having TForm.Scaled=false causes the problem, whereas in some forms, it fixes it:

Update: It turns out that some of my controls use GDI+ and that font behaviour in GDI+ contexts is different than font behaviour in normal GDI contexts, at least for certain third-party controls that use GDI+. That's a major source of headaches. Secondly, there is the spotty test coverage and poorly-defined requirements, for DPI awareness, in the VCL. Some VCL controls are based on MS Common Controls, and while it's fair to say that the underlying common controls probably work fine in high-DPI situations, not all the VCL control wrappers can be guaranteed to work correctly. So, reviewing an application for high-DPI-awareness in all its controls, as well as correct behaviour in all available windows 7 themes:

1. aero glass on, at 96dpi (Default Win7 appearance on most modern hardware)
2. basic theme (aero glass off) but xp themes enabled
3. classic win2000 look where glass is off, as well as xp level themes,
4. high contrast white
5. high contrast black
6. Various Other-than-96-DPI settings

..and the list goes on., and you have a pretty heavy burden, as an application developer. Whether you are a delphi user and use the VCL, or you are an MFC/ATL C++ developer, it seems to me, that supporting all of the various quirky windows modes is a burden almost too heavy to bear. So most people don't bother. Am I right?

Answer 1

You need to manifest that your app is DPI aware with a section like this:

<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <dpiAware>true</dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

If you do this then you won't get DPI virtualization.

You aren't meant to use DPI virtualization so I think there's little point trying to work out how it works. It could easily be dependent on graphics card drivers. It's almost impossible for us to explain why virtualization is behaving this way: you haven't even given any screenshots, hardware details etc. However, you simply shouldn't bother trying to diagnose this. Manifest as dpiaware and it's a non-problem.

For reference I offer you:

• Writing High-DPI Win32 Applications
• http://www.rw-designer.com/DPI-aware