Share via

more comments on my flip3d post...

  • Article

"JoeW" says:

Echoing the point above - does any of the shell components using DirectX provide their own API? How much of WPF is being used here? If there is an unmanaged API will it be public?

MS has been mysteriously quiet about the level of integration of WPF into Vista. It sounds like there are two separate composition engines.

We didn't write two compositing engines for Windows Vista. There's a single composition layer that uses D3D that was originally developed for WPF and is used directly by the Desktop Window Manager to composite the desktop. The public API exposed for using the composition system is managed-only through WPF.

 

The DWM itself offers up a very small API that's focused on enabling applications to have "glass" inside the client areas of their Windows - this will be available for all applications, but was originally developed for clients written in native code like Windows Explorer, so access to these through managed code would be accomplished either by using Managed C++ to load the dll or p-invoke. I realize this isn't ideal in that it doesn't fit with the programming model of WPF, but we'll be sure to provide samples with Beta 2 that should make life easier for folks. If you attended PDC'05, you may have seen a bit about these API's in Jeff Pettiross' talk about building great Aero applications.

 

"J" pointed me to https://mrl.nyu.edu/~jhan/ftirtouch/  and asked if we'd see anything like this in tablet pc's. It reminds me of some of the Play Anywhere work Andy Wilson is doing in Microsoft Research.With regards to TabletPC's, it's certainly possible... N-trig is a company that makes some really neat touch-based digitizers for tablet pc's that could really enable some exciting stuff on this front.

 

"ion" asks if we're doing any work to make non-DWM scenarios better in Windows Vista. None of the DWM-based features (Flip3D, etc.) will be available in non-composited modes, because they were designed to take advantage of the composited desktop. Window repainting will always be better in composited scenarios than non-composited, but you should some some performance improvements in both composited and non-composited scenarios as we do more and more optimization as part of getting closer to shipping.

Comments

  • Anonymous
    February 22, 2006
    Interesting post... thanks for the insight into the design decisions behind Flip3D!

    Whilst we're on the subject of improving the non-DWM interface, could you give an idea of your view on maintaining at least non-damaging compatibility between non-DWM and DWM keystroke combinations?

    Specifically, I'm thinking of things like the fact that pressing Win-TAB on non-DWM systems caused a TAB keypress to be injected into the current application, which may have unexpected/damaging effects (bug 30677 on Connect, closed as "by design") - think of a Hyperterminal window for example, where the char would go to the remote system.

    Similarly, Ctrl-Alt-Tab doesn't do anything at all in non-DWM mode - IMHO it should at least give the same "sticky" behaviour as DWM mode would (although using the old, no-preview tab switcher).
  • Anonymous
    February 22, 2006
    I'm curious as to how the compositing engine handles different drawing methods.  I understand for OpenGL there is a OGL->D3D translator but what about old DirectDraw? With DirectDraw you could draw to the window in many different pixel formats, such as indexed 8-bit color. Does the DWM handle all these cases?

    Also, does the DWM use hardware to accelerate GDI/WPF drawing? Using pixel shaders to rasterize text, etc. Maybe in the future?

    And...how does DWM handle window resizing? Wouldn't this be very expensive to do if each window has a different D3D surface? I'm guessing you'd have to recreate the whole surface every time.

    Just curious.