Partilhar via

How underlying WPF concepts and technology are being used in the DWM

  • Artigo

In the earlier posts I've done on the DWM, there's been a hint of the relationship between it and the Windows Presentation Foundation (WPF, aka Avalon).  This post delves deeper into that relationship.  Because of core OS component requirements (the desktop itself of course being a core OS component) regarding the use of managed code, the DWM itself is not a managed application that directly uses WPF.  However, in almost all other ways, the DWM really can and should be thought of as a WPF application.  Most importantly, it does use the same native composition and rendering module, milcore.dll, used by WPF itself, and it uses it in ways very similar to how WPF uses it.

By the way, I recently did this Channel9 video about aspects of what's discussed here.

Before going further, a quick detour on how WPF applications work.  The application author creates, through XAML or code, a tree of elements that becomes the applications "visual tree".  This visual tree is communicated to the WPF rendering thread as a data structure, and the rendering thread now is responsible for traversing this visual tree and drawing its pixels.  When the application wants to make changes to what is shown, the code they execute results in edits to the visual tree, and the rendering thread re-renders what needs to be re-rendered.  This process of walking this tree and issuing rendering calls is known as "composition".  In a WPF application, the composition and rendering work are done in the milcore.dll module.

So, that's a WPF application.  What about the desktop itself?  The DWM models the desktop as a visual tree where each node in the tree is a window.  And each of these "window" nodes consists of nodes below it that represent the non-client area (frame) and the client area of the window.  It so happens that the client area of the window happens to be a shared DirectX surface that comes from window redirection as described in this earlier post, but from the point of view of the composition engine, the whole desktop is pretty much just another visual tree.  (There's no denying, though, that it's not just any old other visual tree... there are certainly some special optimizations we needed to make in order to get the desktop to the level of performance that it needed to be, but we also hope that those optimizations can make their way back for general WPF usage.)

OK, so now that we've gotten the desktop to look like a visual tree, and even with it being a natural fit, the obvious question comes up: Why?  Why bother?  What do we gain from this?  Why not write the DWM straight to DirectX?

There are a number of substantial benefits that come from building on a general compositing and rendering system.  Here are some of them:

  • Remoting support - the DWM itself can be remoted, and that uses the underlying WPF remoting support.
  • Multiple monitor abstraction - the DWM application needn't concern itself with most of the aspects of how to render across multiple monitors or adapters.
  • Integration of 3D with 2D - the Flip3D feature and the window transitions use 3D integrated into the 2D visual tree.  This support is a key WPF differentiator.
  • 2D tesselated anti-aliased primitives - the underlying WPF technology takes care of this.
  • Update management - as changes are made to the visual tree based on desktop activity by the user, the write invalidations and change propagation occurs in the visual tree.
  • Dirty region management - code within the composition engine ensures that only the regions of the display that are dirty need to be re-rendered, which is an absolutely vital performance requirement.
  • Occlusion culling support - similar to dirty region management, occlusion culling support allows the composition engine not to render content that's changing if it's covered by another part of the visual tree that's opaque.
  • Scheduling - scheduling of frames, maintenance of frame rate, compensation for variability in frame rate is all part of the scheduling subsystem.

All of these benefits come from the use of WPFs composition system.

I'm 95% sure the following question will come up, so let's get it out of the way here:  Is milcore.dll available for public use?   The answer is that in the Windows Vista timeframe, it is not exposed as a public API.  We are certainly looking into what would be involved in exposing it, and clearly understand that there's interest out there for it.

Comments

  • Anonymous
    June 09, 2006
    The comment has been removed

  • Anonymous
    June 09, 2006
    Напоминаю: WPF — Windows Presentation Foundation или Avalon. DWM — Desktop Windo

  • Anonymous
    June 09, 2006
    "Occlusion culling support"...

    Is that why all is black behind a maximized window's frame? It seems to treat them as opaque even with Aero disabled, and it's pretty ugly.

  • Anonymous
    June 09, 2006
    I meant Aero ENABLED, sorry.

  • Anonymous
    June 09, 2006
    The comment has been removed

  • Anonymous
    June 09, 2006
    "Is that why all is black behind a maximized window's frame? It seems to treat them as opaque even with Aero [enabled], and it's pretty ugly."

    That's a visual design choice, not a limitation of the DWM. They blacked out underlying content because the user usually wants to only deal with the content of that window if it's maximized and not have underlying content as a distraction.

    It's discussed in this C9 video:
    http://channel9.msdn.com/ShowPost.aspx?PostID=161254

    and in this post:
    http://channel9.msdn.com/ShowPost.aspx?PostID=161389#161389

    "for max'd windows, [Dark UI elements] puts the focus on the content of the windows. (aka "swelling force") + more obvious difference between max and restored windows"

  • Anonymous
    June 20, 2006
    The comment has been removed

  • Anonymous
    August 06, 2006
    A good amount of ink has been spilled on this blog talking about all the
    cost, nuance, impact, and...

  • Anonymous
    September 13, 2006
    For the most part, the Vista Desktop Window Manager is an end-user feature.  However, because it...

  • Anonymous
    November 09, 2006
    Three products I have been working on RTM’ed this week. Two of them you probably already know about,

  • Anonymous
    November 24, 2006
    Reading through the WPF architecture documents on MSDN and MSDN blogs turned up some interesting hints...

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/1436824-a-voice-from-the-community/2