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