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


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 (12)

  1. JoeW says:

    Thanks Greg,

    You mention 2D/3D integration.  How high-level are these MIL data structures?  I always thought these structures were very basic 2D primitives (Rectangle, Ellipse etc).  Surely it’s overkill to have an unmanaged class for every managed compisition class in the WPF world.  

  2. Напоминаю: WPF — Windows Presentation Foundation или Avalon. DWM — Desktop Windo

  3. Koro says:

    "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.

  4. Koro says:

    I meant Aero ENABLED, sorry.

  5. Martin says:

    Thanks for the great info Greg!  One area of casual concern for me is support for high resolution monitors.  Support for that isnt perfect (eg the mouse moves really slowly, dialogs appear offscrene), but its coming along.  I hope its good for the release.

    I must say im pretty impressed with Vista, though it is a bit on the slow side…

  6. n4cer says:

    "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"

  7. Andrew says:

    "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."

    When a Window is maximized there is no need to show content behind the window, unless the window is not totally opaque.  Occlusion filters elements to prevent unseen elements from passing through the graphics pipeline. This increases performance dramatically.

    In the case you speak of, with Aero on and the black visible, I believe that is a bug.  I have seen it show up when turning Aero on and off in the December CTP.

    ———

    “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.”

    What you are referring to is something totally different.  I think you misunderstood the question.  He was not referring to the dark styling or the darkening of the desktop when the user’s attention is needed (like Flip 3D).  He was referring to how the DWM blacks out everything behind the window, the elements are culled out.

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

    cost, nuance, impact, and…

  9. For the most part, the Vista Desktop Window Manager is an end-user feature.  However, because it…

  10. Three products I have been working on RTM’ed this week. Two of them you probably already know about,

  11. Reading through the WPF architecture documents on MSDN and MSDN blogs turned up some interesting hints…