Responding to Comments on "High DPI Support in Windows Aero Vista"

I received a number of great comments and questions on my last post about High DPI Support in Windows Aero Vista.

Adrian makes a very solid point about applications that do in fact work correctly at high DPI, and scale appropriately, and in general are very good “DPI citizens”, however, they haven’t set the manifest for Vista to claim that they’re DPI aware (and of course they haven’t, since Vista wasn’t around when they wrote their apps).  These are applications that Vista will think are not DPI-aware, and subject them to bitmap scaling rather than letting them render at the true resolution, resulting in a worse experience.  This is an issue that we’ve struggled with on the team, since we don’t want to make the experience worse for apps that have gone to this trouble, yet we do want to provide the benefit for the large number of apps that haven’t.  Based on these conversations, we’ve made some changes post-RC1 that we hope will ease this issue substantially.

Chris Nahr makes a general comment about font scaling, and Joe asks about ClearType.  In both of these cases, rendering windows scaled will result in blurrier, and possibly color fringed text, and without hinting at the larger sizes.  But that’s all because the application doesn’t do the high DPI aware re-rendering themselves.  Those apps that do (see above) we certainly want them to continue to do.  The High DPI Scaling feature is really targeted at the very large class of applications that don’t do this, for which at very large DPI settings, lack of font hinting or potential color fringing is a lesser evil than tiny rendering.

Raiker mentions scaling on vector interfaces good, scaling on bitmaps bad.  We couldn’t agree more.  However, the reality is that most apps are not built on vector-based systems, and those that are can be DPI-aware and scale in a DPI-aware form providing all the benefits of a vector-based system.  This feature is really for the very large class of apps that don’t do DPI-aware rendering and are not vector based.  If you look at Windows Presentation Foundation applications, for instance, those are all DPI aware apps, and will do the full-on vector-scaling thing without being bitmap-scaled by the High DPI feature.

Finally, Michael Giagnocavo talks about Vista Beta 2 DPI scaling being unusable.  Many issues have been fixed then and you’ll find a much better experience in RTM and in the RC1 that’s out now.

Comments (8)

  1. Dean Harding says:

    You know, I’ve been running Vista (Beta 2) at 144 DPI, and I checked that "Use Windows-XP style scaling" – which basically turns off the bitmap scaling.

    The reason is that I’ve found most app actually work PROPERLY in high-DPI situations – not the other way around. So I was forever checking their "disable DPI scaling" checkboxes in the "Compatibilty" tab.

    Notable exceptions are basically anything that provides a custom "skin". But mostly it works pretty good, and the blurryness that the bitmap scaling does means I can’t use an app for more than five minutes without going cross-eyed.

    One strange exception is Windows Live Messenger. MSN Messenger (the old version) scaled properly, but WLM does not…

  2. bitbonk says:

    WPF device independent pixels for dummies!E17530AA6EFF7871!143.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink

  3. Sven Groot says:

    Again a mention of using manifests to indicate your app is high-DPI aware. Again without any mention of how to do it.

    All I can find in the Windows SDK is SetProcessDPIAware which I can’t use (it causes all sorts of scaling issues if you call it in a .Net 2.0 app, whereas the apps behave correctly if you just check the "don’t scale" box on the compatibility tab). I’d love to see if the manifest approach works, but I can’t find how to do it. Is there any documentation on it? Is it even implemented yet?

    On a sidenote: the big problem with high DPI scaling of bitmaps is that it seems that most applications (including Windows Explorer, even in Vista, as well as Office 2007) seem to scale them using the GDI StretchBlt function, which looks absolutely terrible. I guess it’s too late to switch Windows over to some form of scaling that actually uses some form of smoothing, even if just bilinear. At least the DWM scaled apps don’t have this problem, but the blurry text makes them give me a headache.

  4. Dean Harding says:

    Sven: You have to call it before absolutely anything else. I usually do it in the same place I call Application.EnableVisualStyles() – seems to work for me (though I haven’t done extensive testing).

    But I agree that a quick post on how to do it the "manifest" would be nice…

  5. Sven Groot says:

    I know, but even if it’s the very first thing I call in Main(), the autoscaling still messes up.

    I think it has to do with font scaling. .Net 2.0 scales forms based on font size, and by default it uses the DEFAULT_GUI_FONT returned by GetStockObject, which changes size with the DPI settings but has a number of drawbacks, including not adhering to the user’s font size settings and always returning MS Sans Serif (even though you’d want it to use Tahoma on XP and Segoe UI on Vista).

    So I make my forms use a different font, which does use the correct font for the OS and adhere to the font size settings. When I do this, in combination with SetProcessDPIAware, it doesn’t scale correctly anymore. Like I said, if I don’t call that, but check the "disable DPI scaling" option on the compatibility tab, it does scale correctly.

  6. Esta build (7100. 0. winmain_ win7rc. 090421- 1700) foi compilada na passada Terça- Feira e ao que parece já começou a ser distribuída a parceiros OEM.