Wow… lots of great interest and comments in my previous post on “Under the Hood of the Desktop Window Manager”. Rather than attempting to comment inline, I figured I’d try to address in a separate post. So here goes:
Anonymous: I’d like to know why DWM can’t just use the alpha channel of the buffer that Avalon draws to, to be able to do completely hardware accelerated irregular shaped and alpha blended windows, but instead has to drop Avalon HW acceleration and go to software rendering…
The above is not the case, if I’m parsing correctly. An Avalon application is effectively a DirectX application, and renders to a DirectX surface. This can be a video memory, hardware accelerated surface, and its display through the DWM does not require that it be booted out to software.
Stephane Rodriguez: “Tear free experience”
How is this possible? Doesn’t this depend on how much is getting drawn?
Two decades ago, on machines like Atari ST and Amiga, it was all about the vertical blank. People used to write applications (demo) that would draw based on the vertical blank frequency, avoid the drawing spot, resulting in smooth scrollers and so on. Whatever happened to this?
In other words, I don’t think the tear experience scales well if you drawing too much on the screen at the same time, say you are running a couple videos concurrently.
And I still fail to see how tear-free experience will make mom and dad feel excited about Windows Vista. Sorry, it had to be said.
Today’s “tear free” isn’t the old Atari/Amiga approach which as you say tried to fit everything into vblank. Instead, DirectX is able to maintain a “flip chain” of buffers and swap between them for what’s displayed on the screen. The “flip” happens at a very low level in the system and does occur during vblank. But it doesn’t require drawing. The video card then simply scans out the new front buffer, and treats the old front buffer as the back buffer that the application (in this case the DWM) renders into.
Tear-free making Mom & Dad excited about Windows Vista? Yea, can’t help you much there :-), but hopefully the accumulation of all the good stuff across Vista will be enough.
[3/18/06 – Update – tear-free exciting Mom&Dad. It occurs to me that I may have been too flip in this response. Tear-free on it’s own won’t excite them, however, this is just one of the many quality improvements being made where the sum of which will lead to just a better, more solid feeling product. Kam VedBrat also talks about this effect.]
JoeW: I would like to know more about the public APIs. Specifically I would like to know how Vista’s native dialog boxes are rendered (message box, explorer windows etc). Do they still use GDI or do they use an unmanaged composition engine?
More on the public APIs in a later posting. However, regarding how dialog boxes are rendered, there’s fundamentally no change here. GDI is still used, and the windows redirect through the DWM just like any other GDI application. The primary rendering that the DWM itself is responsible for is the non-client areas of windows.
David Larsson comments on issues he’s hitting with High DPI mode in the latest Vista CTP. I can say that many of those rough edges are being addressed.
Another David asks about memory requirements for DWM given that windows contents are stored. It’s definitely the case that there is a larger memory requirement when running the DWM — but rather than getting further into it, I do expect that to be discussed in a future posting.
Shawn Oster: As I’m reading a few dozen questions come to mind. You hit on some of them in your “upcoming topics” hit list but here are the things that sparked:
1. How signifigant will hardware acceleration be to Glass? It used to be there was the 2D benchmarks for work apps then the 3D benchmark for the fun things. An amazing game card would often be horrible at having a lot of small Excel/Word/Visual Studio windows open.
2. One of the first things new developers learn is to do their own screen buffering, to a bitmap, metafile, etc. Does the DWM change that since it’s already buffering?
3. What kind of impact will this have on apps like Photoshop? Are there things raster image editing programs can do to improve speed if they are running on Vista?
4. If you are running old hardward does everything still go through the DWM? Like inside a Virtual PC?
5. How much control will we have over DWM? For example could someone create Flip/Flip3D as a stand-alone app? The nerdling fun side of my brain imagines interfaces a la Minority Report (minus the gloves and Tom Cruise).
6. Hmm, speaking of the Minority Report UI, how well will video drag?
7. How heavy a load does DWM put on the system? I remember when shell replacements were big (LiteStep, geoShell, Cloud9, etc) and the goal was always reducing load while giving UI goodness. Sounds like DWM could be that as long as it isn’t seen as a boat anchor.
Looking forward to more blog posts on this subject. Try to come up for air just a wee bit more often 🙂
and answers to those…
- HW acceleration is a very significant determinant of DWM performance. Particularly video memory transfer rate. Windows Vista will enable the DWM on hardware that’s capable of supporting it, and we do expect that to be a wide range of hardware.
- Application doing screen buffering: I’ll address that further down in response to another person’s question.
- The DWM itself doesn’t really have substantial impact on apps like Photoshop (other than the buffering issues). There may be other Vista advice they can follow, but I don’t have that.
- Things will go through the DWM if the hardware qualifies, including being sure that a Vista Display Driver Model class graphics hardware is in use. More on that in a future post.
- More on that in a discussion on DWM APIs
- I assume you’re referring to the issue on XP and before that when you drag a window with video, the video lags the window. That’s because in those systems, hardware overlays are being used. In Vista, the window is composited, and everything is in sync, so no more lag.
- We’re working hard to be sure that the DWM doesn’t put an overly hefty load on the systems that qualify for DWM.
DCMonkey asks about resize semantics under the DWM. This is something we’re working on improving, and have made good progress there.
Kirill Osenkov asks: Does it mean I should get rid of my (now unnecessary) custom back buffer when I port my app to Vista? Does it also mean that all flickering applications will automatically become flicker-free?
Yes and No. Applications no longer need to double buffer when the DWM is running provided that their purpose in double buffering was to avoid video-system induced tearing. However, double buffering is also frequently used by applications to avoid “structural tearing” — for instance, being sure that this triangle and this rectangle are presented atomically. This is not something that the DWM can help with. So it really depends on your usage of double buffering, and your original source of flickering. Each application author is going to need to evaluate that for themselves.
HTK asks whether the first screenshot with the bigger buttons is a real screenshot. No, it’s not, sorry I wasn’t more clear. That was really intended to show the design element/sensibility for Aero. All the other Windows Vista images are screenshots.
Chris Nahr asks about getting rid of traditional WM_PAINT processing altogether, and just drawing new elements as required. This is absolutely not the direction that this is going. WM_PAINT is still used in many places throughout the system for invalidation and rendering requests of client areas. Chris also asked about higher resolutions. That’ll be covered in a future post on high DPI support.
ion and other asked about jaggies/aliasing in Flip3D. Yes, this is certainly a known issue that we’re actively working on addressing.
Eli asks about glass blurring, and DWM accelerating GDI. Pixel shaders are indeed used for the blurring component of the “glass” look. And DWM does not accelerate GDI rendering. However, due to the nature of desktop composition, operations like window moves and resizes can be faster/more responsive because underlying content need not be re-rendered.
Anonymous asks about text rendering. The caption area text rendering is going through the same text rendering that WPF uses, and thus is subpixel ClearType. Furthermore, there is an exposed API in the theming DLL for rendering text atop “client area glass” — more on that in a future post.
ping pong asks if DWM is written in a managed language. It is not. It uses the same unmanaged rendering component that the WPF/Avalon system does.
Mike Dimmick talks about running Java applets in Sun’s JRE results in the DWM being disabled. Yes, Sun is well aware of this and is proactively working on a fix. And you’re right, that locking the DirectDraw primary surface has this result, since the desktop now needs exclusive access to the DDraw primary for the DWM to work.
DGC asks about memory usage. Yes, there is a larger memory footprint with the DWM. More on that in a future post.
KJK::Hyperion asks about total abuse of this technology through 3rd party programmability. But of course ☺. We do have a certain amount of programmability of various key features like glass, thumbnails, and control of composition. More on that in a future post.
Keith Patrick and MueMeister both wonder about the relationship between DWM and WPF, and if there is any. There most definitely is a big relationship. Both DWM and WPF are written on the same unmanaged rendering layer that sits above DirectX and is responsible for all the actual rendering in both WPF and DWM.