hwnds and the DWM

I wrote that "All Avalon elements on the screen are ultimately backed by hwnds."  Yep, even on Longhorn.  One of the changes we made to USER and Win32k.sys in Longhorn is that when the DWM is on, all top-level windows (Avalon or otherwise) are rendered to an offscreen bitmap.  And that implementation is mostly the same as layered windows; a good portion of the work in USER these days is performance and compatibility tweaks for that code path.  Which is also why there's a good chance of us fixing most Avalon layered window issues on Longhorn (although not guaranteed, since layered windows aren't exactly the same as DWM top-level windows)

On a sidenote, when we talk about DWM most people think about the output redirection part of it -- taking applications that were designed to render directly to the screen and "redirecting" their output to an offscreen bitmap which the DWM can then draw wherever it wants.  But most people, including within the Avalon team, overlook input redirection -- it doesn't matter where that window is drawn if mouse input doesn't get to that window.  So the DWM tells USER where each window is so it can direct input as appropriate, as well as how each window is scaled.

Comments

• Anonymous
  July 12, 2005
  Can you please explain the relationship between Win32 subsystem and WinFX. In PDC it was told thar WinFx replaces Win32. Now it looks like USER and Win32K are still in use
  
  Thanks
• Anonymous
  July 12, 2005
  Cool! Thank you, Nick, your post make it very clear to understand. In-process Avalon -> GDI -> DWM -> Driver.
  
  Just one noticeable exception from this clean sharp picture.
  
  Is DirectX output is going through DWM too? How it is applied to performance of DirectX?