There’s an interesting little checkbox buried deep in the DPI scaling settings in Vista labeled “Use Windows XP style DPI Scaling”. From what I’ve read about the new desktop composer in Vista – un-checking this effectively turns on full DPI scaling for applications that don’t use newer resolution independent frameworks, and haven’t marked their apps as DPI scaling aware. Vista’s support for high resolution displays represent some interesting challenges for application developers who use older developer tools such as the MFC and Windows Forms. This checkbox option makes for a really useful little option for developers who need to check to make sure their apps are working well with the Vista Desktop.
Checking the option causes non-DPI scaling aware applications to be scaled similar to the way they would have been in XP – the application is told the default system font sizes and icon sizes are larger than the typical size you would find in 96 DPI. If the application is well designed, this won’t have much of an effect on the UI, graphics and text will simply be larger on high-DPI displays, which for the most part will look the same as they would on lower DPI displays. Older frameworks will either resizing icons and bitmaps, or simply leave them the same size, making them appear smaller. In a lot of apps, this can cause funny anomalies in compact user interfaces, where text labels and other elements might slightly overlap other UI elements in the same window because the developer never anticipated a system font size larger than the typical dimensions found on 96 DPI desktops. Icon’s and bitmaps may look blurry because they weren’t designed to be scaled to these levels.
Un-checking this option will turn on full scaling of all non-DPI aware applications which acts as a compatability mode for non resolution independent apps. The effect is similar to resizing an image in a photo editing program or the scaling of textures in 3D games – fonts will be slightly blurry due to scaling effects of the composer. At really high DPI settings, fonts will become unreadable. The composer is literally resizing the application UI by rendering it’s interface to a off-screen surface and then resizing that surface before sending it to the screen.
A lot of 3rd party apps aren’t high DPI aware, so you’ll get this blurring effect in these apps with the checkbox unselected. You’re only going to see this on desktops where the user has a large cinema display and they’ve adjusted their DPI to a custom level. At 96 DPI on a typical monitor, either setting will look the same. In my case though, I’ve scaled to a custom level – 108 DPI which just happens to be where I like it. I can fit more on my desktop and better leverage my display without having to squint at the screen. It’s a very personal setting which has a lot to do with how good your eye sight is and how far away from your monitor you sit.
By default “XP Style” scaling is enabled for any display setting up to 120 DPI. Beyond that, Vista will default to “Vista Style” scaling. Overall – Win Forms developers are going to need to start paying attention to high DPI UI issues to better handle large screens, myself included. (Windows Presentation foundation apps are resolution independent, so WPF developers have nothing to worry about.) Daisy for example, which is a Win Forms application was not DPI aware. The first time I launched it on Vista with XP style scaling, I had a couple of properties dialogs that had some overlap in the UI. With Vista style scaling the blurrier UI text was annoying.
User’s in general should stick with “XP Style” scaling. If you come across an application that isn’t well designed for larger DPI’s make sure and let the developer know. Even if they don’t have a high resolution monitor, Vista will allow them to scale up the DPI settings to test for anomalies.
Side note – old school MFC hackers need to use a dependency manifest when marking their apps as DPI aware. Calling SetProcessDPIAware in init instance is too late – the MFC library will have already collected up a bunch of system metrics information by then.
Update – Rob Relyea adds in the comments that WPF developers have a few issues to deal with when using raster based graphics in their WPF apps.