There’s a big effort going on for Windows 7 to make High DPI more usable by the masses. (You can read an article on the engineering aspect of that here.) You can even switch DPI with nothing more than a simple logoff, rather than the reboot required for Windows Vista. (It’s still not instantaneous, but it is progress.)
So, since I have a 1920 x 1200 screen on one of my laptops, I figured I could give it a go – even at high DPI, I’d be able to fit enough onto my screen in order to get some meaningful work done. So, why not?
My experience so far: text looks awesome. It’s just a pleasure to look at the screen now – everything is so much more readable. (I’m going to find it hard to go back, if I ever do.) I figured I’d share a few tricks.
First, we added a new means of doing DPI scaling. There is the old way, which is to adjust the system metrics and trust the application to handle things correctly, and the new way, which is to let the application run rendering to a 96 dpi off-screen bitmap, and have the desktop compositor resize things to make them bigger (leaving them fuzzy in the process, much like you get the fuzzies when not running at your LCD monitor's native resolution). Oh DWM, is there no end to the gifts you can give to us?
Most people don’t know about these two methods, because we auto-chose them for you until you’re in advanced mode. If you are only going to 125%, then we use the old method – higher scaling switches over to the new (DWM) method. In fact, the basic screen won’t even give you an option that would enable DWM scaling:
You can see the option when you get into the advanced dialog, accessible by clicking on Custom DPI…
What I did was switch up to 125%, but then disable Windows XP style DPI scaling (in other words, enabled DWM scaling – I have absolutely no idea why we use the language we do here, it seems completely confusing).
Two things happen as a result. First, Sidebar, which is incredibly misbehaved at high DPI, seems to work better with DWM scaling (although I have one gadget that loses a tiny bit of some text). Second, it defaults all applications to rendering at 96 DPI and then zooms them up, reducing the number of rendering bugs, but giving me the fuzzies.
And I hate the fuzzies.
An application that wants to just get the scale and opt out of DWM scaling need only manifest itself or call SetProcessDPIAware. I’ve discovered that almost nothing does this. (Office being the notable exception – they are OUTSTANDING at High DPI. Oh, and Windows Live Messenger, which marks itself as high DPI aware despite being laden with High DPI bugs (try using emoticons). I thought perhaps I had marked it somewhere myself by accident, but sure enough:
C:\Users\cjacks>sigcheck -m "c:\Program Files\Windows Live\Messenger\msnmsgr.exe"
sigcheck v1.54 - sigcheck Copyright (C) 2004-2008 Mark Russinovich Sysinternals - www.sysinternals.com
c:\program files\windows live\messenger\msnmsgr.exe: Verified: Signed Signing date: 1:02 AM 9/9/2008 Publisher: Microsoft Corporation Description: Windows Live Messenger Product: Windows Live Messenger Version: 14.0.5027.0908 File version: 14.0.5027.0908 Manifest: <?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">
<assemblyIdentity version="18.104.22.168" processorArchitecture="x86" name="Microsoft.MessengerService.Messenger" type="win32" /> <description>MSN Messenger Service</description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="22.214.171.124" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b" /> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity version="126.96.36.199" processorArchitecture="x86" name="UCCAPI" type="win32" /> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity version="188.8.131.52" processorArchitecture="x86" name="VVPltFrm" type="win32" /> </dependentAssembly> </dependency>
<!-- resolves a crashing bug with the Philips webcam driver --> <file name="vphc700.dll" />
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3"> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo>
<asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/Wind owsSettings"> <dpiAware>true</dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly>
Yikes. Let’s hope they fix those bugs (I’m using a beta right now).
The big thing I do is to set everything that works right to render at high DPI without being scaled, because as I said I hate the fuzzies. You can do that in one of two ways. First (what I mostly do) you can set up a local custom shim database using Compatibility Administrator and simply apply the HighDPIAware shim or layer to every application that you want to render crisply. If it then misbehaves, you can remove it.
Of course, we knew that most mortals aren’t interested in creating shim databases all the time, so we also allow you to do this from the compatibility tab:
You can simply check the “Disable display scaling on high DPI settings” to apply the HighDPIAware layer to the process, and you’ll be on your way.
For people writing software, I’d sure love it if High DPI entered the test matrix. And, on our end, we should be providing more guidance. Together, we can get there, and we’ll have insanely dense displays with beautiful text. But, if I never lived it, I could never feel the pain, or enjoy the pleasures of the experience.