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.