USER & GDI Compat, part 3 — High dpi

Pixel sizes have been roughly constant for a long time, but LCD manufacturers are increasingly coming out with monitors with smaller and smaller pixels, aka high dots per inch (dpi).  If an application uses the same number of pixels on a high dpi screen as it does on a standard 96 dpi screen, the application will look really small.  Windows Vista introduces the ability to scale applications that were written for 96 dpi screens, which it does by rendering the application’s bitmap at a larger size.  Like all bitmap scaling, this can result in some blurriness, but otherwise gives a correctly size and properly rendered image.  Applications can also decide to support high dpi natively, which will give the crispest possible look.  Currently an application can turn off scaling & declare itself dpi-aware by calling SetProcessDPIAware(); we’re looking to add a manifest-based way to declare this as well.  For more information about writing applications that natively support high dpi, see (coincidentally written by me in a former life).

The rest of this section talks about potential problems with non-DPI aware applications.  Applications ask Windows questions like “how many pixels wide is a scrollbar”, so when a 96 dpi application asks, Windows Vista lies and gives the application the 96 dpi answer.  There are however cases where Windows doesn’t lie, sometimes because Windows Vista hasn’t learned the right lie yet (please give us this feedback), and sometimes because the “right” answer depends what the application is trying to do with the answer.  (Screen coordinates often raise this problem)

Most compatibility problems come from these imperfect lies.  Things to look for when testing:

  • Text is clipped (partially hidden)

  • Text is too big

  • Something is drawn at the wrong size or in the wrong place

[update 6/4/2008 — fixed hyperlink to the high dpi paper]

Comments (5)

  1. Dean Harding says:

    This is a topic that is very dear to me. I’ve had a high DPI screen on my laptop for couple of years now, and I can’t possibly imagine ever going back to 96-DPI.

    On Windows, a fairly surprising number of applications "just work" because the native Win32 API (and hence anything built on top of it, like MFC) use "dialog unit" (I think is the term) for laying out windows, which are DPI-independent. This means that regular windows and dialogs are all nicely scaled up, text is crisp and clear and so on.

    The main issues are when images are involved or when applications try to do their own "custom" skins (which in 99.999% of cases, completely ignore non-96-DPI screens [and in fact most usability rules in general, but that’s another rant])

    The other thing that doesn’t work well is .NET 1.x WinForms applications. For some bizare reason, a step back was taken with .NET and all units are directly in pixels. But then, .NET will SOMETIMES scale dialogs and windows (based on some bizarre heiristics that I could never figure out). Which meant that for the longest time applications like Paint.NET never looked right on a High DPI display.

    It was even worse if you tried to develop a WinForms app on machines with different DPI settings. It totally confused the scaling heuristics if you loaded a form developed on a 96-DPI display into a designer on a (say) 144-DPI display.

    I believe that’s mostly fixed in WinForms in .NET 2.0, though I haven’t had much chance to play around with it. I also heard that it was also fixed in Avalon (where the units of render were called "pixels" but they’re actually DPI-independant units, which just happen to have a 1-1 mapping with pixels in 96-DPI desktops).

    Anyway, that was my understanding until I read your blog post. Is the call to "SetProcessDPIAware" for GDI/USER applications? What happens to those apps which already work in High DPI displays (because they specify all their dialogs using "dialog units")? Will they need this manifest update so as not to look "blurry" when scaled? And I assume the High-DPI stuff is not needed in Avalon apps, since all that is taken care of automatically, right?

  2. Good questions.  Plan is for existing applications that work well at high dpi (e.g., Office), we’ll have a checkbox in the compatibility properties tab, and we’ll provide shims for the applications we know about.  The checkbox isn’t in the February CTP, though…  I run all my systems at high dpi myself, so I’m eagerly awaiting the checkbox!

    WPF applications will handle high dpi out of the box.

  3. Dean Harding says:

    Yeah, and I guess if you add the manifest property, I can at least do it manually for apps that you guys don’t know about as well.

    Can’t wait! 🙂

  4. This content will make it into the master compatibility document in the next month or so, but in the…

  5. A good amount of ink has been spilled on this blog talking about all the

    cost, nuance, impact, and…