Freigeben über

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

  • Artikel

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

  • Anonymous
    September 13, 2006
    The comment has been removed

  • Anonymous
    September 14, 2006
    WPF device independent pixels for dummies

    http://bitbonk.spaces.live.com/blog/cns!E17530AA6EFF7871!143.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink

  • Anonymous
    September 14, 2006
    The comment has been removed

  • Anonymous
    September 14, 2006
    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...

  • Anonymous
    September 15, 2006
    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.

  • Anonymous
    January 26, 2008
    The comment has been removed

  • Anonymous
    April 26, 2009
    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.

  • Anonymous
    May 31, 2009
    PingBack from http://woodtvstand.info/story.php?id=5515