High DPI Support in Windows Vista Aero


A good amount of ink has been spilled on this blog talking about all the
cost, nuance, impact, and techniques we go through to get a composited desktop. 
Less ink is spilled on the benefits of the composited desktop.  Those were
most broadly covered in

this initial post
.  I’d like to expand on one such benefit here — High
DPI Support (or High Resolution Support).

Monitor resolutions are going up while prices are going down.  In
general, pixel density is going up as well.  Both on laptops that are
regularly 120 DPI and 144 DPI these days (as opposed to the typical desktop
experience of 96 DPI), and on desktops that are getting bigger and denser
monitors.  This can make for crisper, less jagged display of content. 
However, in order for this to work, applications typically need to do work to
deal with different display resolutions.  (This is not always true… for
instance, Windows Presentation Foundation applications are natively
resolution-aware, and the application developer needn’t worry about it.) 
When applications aren’t written to adapt to different resolutions, they just
start to look smaller and smaller on higher and higher resolution monitors. 

The seminal article for how to write your GDI/GDI+ applications to be DPI
aware was written way back in 2001 by my colleague
Nick Kramer, and can be found

here
.  This is ultimately the best approach an application can take. 
However, not all applications do this, and yet users of course use these
applications while they’re running in a higher DPI environment.  This is
where the composited desktop re-enters the picture.  As you recall, when
the DWM is running, applications render to an offscreen bitmap.  When the
DWM recognizes that an app is not DPI aware and just rendering as it always
does, but that the desktop is set to a non-standard DPI, then the DWM goes ahead
and renders the window at a larger size.

This "rendering at a larger size" results in the app being somewhat fuzzier
and not as crisp as if it were being rendered natively at the correct
resolution.  However, it’s the "correct" size for everything else on the
desktop, and typically represents the much better option between rendering at
the right size somewhat fuzzily; or crisply but at a size much too small.

For the purposes of this blog, there are some interesting tidbits about the
High DPI rendering that are worth discussing:

  • As

    this earlier post
    describes, the client area of the window is just a
    bitmap.  Because of the way the DWM works and how it sits atop WPF
    technology and thus atop DirectX, scaling the client area is really just a
    matter of modifying a scale transform on the appropriate node of the "visual
    tree" that describes the desktop.  This notion was described

    here
    .
  • When that transform scaling is performed on the visual tree, ultimately
    in DirectX, this results in performing a texturing operation with the same
    sized texture but a larger mesh (the target client area), resulting in
    stretching the client area bitmap. 
  • The Non-Client Area (the window frame) is not scaled uniformly with the
    client area.  As in non-DPI scaled situations, it’s "painted"
    separately.  It’s not simply subjected to bitmap scaling because for
    the frame, we can natively scale it, and choose elements appropriate
    for the target resolution, render caption text appropriate for the target
    resolution, etc.
  • While one can imagine any scale factor coming about as a function of the
    target DPI resulting in windows that land off of pixel boundaries and
    represent fractional pixel contribution.  However, we avoid this and
    clamp our scaling so that we always remain on pixel boundaries and remain as
    crisp as possible, within the confines of the graphical filtering algorithm
    in place.

More details for the app developer: 

  • The preferred mechanism by which an application will be able to declare
    itself High DPI aware under Windows Vista will be via the manifest. 
    Look for upcoming MSDN documentation discussing how to do this.  In the
    event where a manifest isn’t appropriate/available (for instance, when
    writing a library or framework), the the library should ensure that the "SetProcessDPIAware"
    API is called before creating any UI.

  • Nick writes a bit more
    about High DPI in the context of USER and GDI
    compatability.
Comments (21)

  1. Joe says:

    Thanks Greg,

    How is ClearType affected by this?  The pixel boundary scaling would need to be careful about this is the app was using ClearType.  I could imagine some strange discoloration would be visible.

  2. Michael Giagnocavo says:

    So will all this high DPI goodness make it into Vista RTM? In Beta 2, turning up the DPI still is totally unusable. Even most of the Windows dialogs and windows get totally screwed up. Also, images still seem to be scaled horribly (no smoothing at all), and there doesn’t seem to be high DPI versions of any of the graphics Vista uses. Heck, even the Start button gets all screwy at high DPI.

  3. Raiker says:

    With old (plex days) concept zoom was really cool. With DCE and vector interface concepts it gived really advanced and useful possibilities. DPI-scaling much more bad.

  4. Chris Nahr says:

    Greg, I’d also like to know about font scaling. So are you saying that text is simply scaled as part of the total client area bitmap? The scaling algorithms and hints of the OpenType font program will be ignored?

  5. Adrian says:

    As someone who has been making DPI-aware Windows programs since before manifest files were invented, I’m frustrated by the fact that my old programs’ layouts are being broken by Vista.  I have a couple programs that run at both 96- and 120-dpi resolutions on every version of Windows from 95 through XP.  But on Vista with 120 DPI, the text is not only fuzzy, some of it is *clipped* (apparently due to rounding differences between the lies returned by the system and the actual scaling performed).  The only way to fix this is to build a new version that uses the API or a manifest file.  (And the API doesn’t seem to work in current Vista betas.)

    Why not maintain the status quo and make the non-DPI-aware programs use a backward compatibility option, instead of breaking programs that got it right from the start?

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

  7. 이 블로그의 좋은 점 중에 하나는 댓글이나 메일에서, 주제에 대한 세부 사항정보와 데이터에 대해 좀 더 깊이 있게 이야기할 수 있는 점입니다. 여러분의 질문이나 의견에 대해 보다 깊이