Back on Channel 9!

  • Article

In late December, I sat down for another interview on Channel 9. It took a little while to "bake" over the holidays, but it finally got posted about a week ago.

I know some folks are asking for the source code for the demo that was shown, you can download it from here. This sample was based on some code that was written for other demos we did internally, so if the part of code to extend glass into the window looks familiar, that is why.

There's been some lively discussion on the thread, so I'll take a moment to address some of the comments.

DigitalDud mentioned the need for new display drivers to do composition. I've talked about the benefits of composition in the past, but it's worth discussing the new driver model briefly. The new driver model is really a separate thing from Desktop Composition.

With the new driver model, the biggest change was moving a great deal of code out of kernel mode into user mode. There were meny motivations for this - including, but no limited to One motivation behind this was that video drivers are increasingly doing a great deal more language processing than they had in the past, due to new functionality like shader processing at the pixel level and for geometry.  Moving this processing up into user mode means it's less likey that an application can cause the driver to crash in kernel mode - in other words, far fewer blue screens.

Desktop composition does take advantage of the new driver model, in that it enables better support for more than one application using the GPU simultaneously, sharing graphics memory, and managing graphics memory together.

DCMonkey asked about resize behavior . The biggest challenge with improving resize behavior is application compatibilty. For new apps, like those written in WPF, we had more latitude to change what happened in the application by default when you resize it. In WPF, you don't manage your DC or your DX surface directly - the framework does that for you. So we can make sure that the framework does something "DWM friendly". For existing Win32 applications, and even some Windows Forms applications, we need to make sure that we don't do things that change the expectations that applications already have. Some applications do processing on the resize loop by listening for and reacting to WM_SIZE messages. Sometimes those applications don't get that work done in less than 16ms (which would be required to do a resize at 60FPS assuming no system overhead). And of course, the system does have overhead so the applications don't really get their whole 16ms - what they get varies from system to system based on hardware.

There are a number of approaches that can be taken to keep these things in sync and looking smooth - one way to do it is to not update the window frame until the contents of the window have drawn. The downside to this, is that then the window updates will lag behind the mouse-pointer movement. Apple's OSX exhibits this behavior pretty commonly (at least Tiger does on the Mac Mini we have in the office). Another approach is to have the window frame track the mouse, and use a default brush to fill the new window area until the window gets around to repainting - that's what we do in Windows Vista.

If the application chooses to draw glitchy stuff in that resize loop, there's not a lot we can do. The one thing we can do is focus on making sure that the amount of processing that happens in DWM.exe during resize is minimal, and we spent a great deal of effort on that front.

There was some discussion of .NET 2.0 executable shipping in Windows Vista. It's true, there are none (to my knowledge). That doesn't mean that Microsoft isn't investing in great experiences built on the .NET framework. The Max project was probably our first major public endavour in building a great user experience on .NET. That project has closed now, but there are other things happening as well. There are the Expression tools, and there's also the new Windows Live for TV Beta, which is an extension to Media Center on Windows Vista that was built using the framework. I'm sure there are more things like this coming as well.

Thanks for all the great questions & comments on the interview. Its always fun to do these, and be able to participate in discussions like this!

Comments

  • Anonymous
    January 29, 2007
    Thanks for your follow-up, Kam--that is great information, and I'm keeping it in my journal of "useful knowledge about Windows." I have a question related to the shifting balance of kernel-mode and user-mode code in Vista (and I'm not much of a dev, so forgive my ignorance on this!).  My greatly generalized understanding of this balance has increased performance on the kernel side and a host of other benefits on the user side (again, very generalized).  Also, my understanding of the performance issue is that context-switching is a very expensive operation.   I'm curious... with the advent of dual-core processors becoming the norm, is it possible (and would there be a worthwhile performance benefit) to assign--or far more likely and beneficial (I'm guessing), prioritize--kernel-mode code to one CPU, and user-mode code to the other?  

  • Anonymous
    January 30, 2007
    PingBack from http://tiger-osx.blogoland.info/article/694561/Back-on-Channel-9/

  • Anonymous
    February 14, 2007
    Great video & article, it is the first place I have found how to effectively draw the controls on top of the glass surface. I tried different variations of your code converted to vb as well as substituting in code from a vb app that I had working but couldn't put controls on the glass. The main thing that happened was either a black background or the controls didn't render properly. So, instead of fooling around more, I just took the c# code and created a class library. Then I thought it would be nice to be able to add dragging from within the library so I added a property to enable/disable window position dragging. This is great in all but a problem occurs with the positioning of the elements on the window. If I take my window and draw my "container" that will not use glass, and position the other controls through margins too, I can then just pass the containers margin property and all is well. If, however, I lay the window out with stack panels or grids and take the margin of the panel… well I'm sure you don't even have to think about what happens. So the question I have after all this rambling; is there a way to find the actual left, top, right and bottom properties relative to the window? I was thinking maybe a recursive loop passing in the parent of each control until the parent type is window and then adding all the margins up. That is really my only thought aside from a property the window would expose (though I haven't found). I guess I'm going to try to try the recursion but I have a weird feeling that the width, height and alignment of some items my effect the integrity of the calculations...

  • Anonymous
    February 17, 2007
    Zac - thanks for the comments. I'm not sure I understand your question entirely. I think you're looking for coordinates relative to the non-client area of the window? if that's what you want you need calculate the size of the non-client area based on your OS and its settings.

  • Anonymous
    February 20, 2007
    I was just trying to specify a main panel object for content and have the rest be glass. When using a grid, you can't pass the margin of the panel inside it because its margin isn't relative to the window. Anyways, I think that the TranslatePoint method of the window might work. I saw in while digging around in the documentation. I haven't had a chance but will post the code if I get it to work.