Freigeben über

High DPI Support in Windows Vista Aero

  • Artikel

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