§ ¶How to kill Aero Glass on Vista beta 2 with DirectDraw
I figured out why VirtualDub causes Aero Glass to go nuts on Vista beta 2, and the actual reason turned out to be rather bizarre. Had nothing to do with window hierarchy layout.
Aero Glass uses the Desktop Window Manager (DWM) to composite the display, so certain drawing operations from programs that the DWM can't emulate will cause the DWM to disable composition until the program exits. Typical operations that kill the DWM are those that access the full display or those that appear to do so (that the operation is limited to a window can't be determined). Well, I'm not locking the backbuffer or doing anything naughty, but it turns out this was what was disabling the DWM:
// get surface desc
if (FAILED(mpddsPrimary->GetSurfaceDesc(&ddsdPri))) {
DEBUG_LOG("VideoDriver/DDraw: Couldn't get primary descn");
break;
}
Merely calling GetSurfaceDesc() on the primary surface causes the DWM to disable itself. Changing this to use GetDisplayMode() fixed the problem, and it turns out that even good old DirectDraw 3 will work just fine with Aero Glass as long as you use a clipper when you blit to the primary. If you don't use a clipper, bye bye DWM.
Another oddity of beta 2 is that it seems you can create a DirectDraw overlay surface, but it never shows up and you see nice color key green instead. It's not a problem with the color key, because I can disable it and I still won't see an overlay. Sigh.
Comments
Comments posted:
Death to Overlay!
Kidding aside, overlay implementation on recent hardware REALLY REALLY sucks. Very low quality scaler (both ATI and NVIDIA). Shame VMR9 isn't very well thought out either:
1. No Gamma support in hardware anymore.
2. Luma range seems to be 16-235 on the desktop unless you use a special registry flag (with NVIDIA, not sure about ATI).
3. Unless you use your own customized renderer (VMR9 renderless mode), you get screen tears in high resolution (1080p) with VMR9 Windowed/Windowless because these modes blit the video to a regular window handle and if your computer/card isn't fast enough to do the blit before v-sync kicks in, you get a nasty tear (both ATI and NVIDIA under some system configuration). And even worse, some models don't even respect V-Sync in Renderless mode unless you're using Exclusive Fullscreen Renderless mode (which means you can't use any non-Direct3D interfaces).
I hope vista comes with a better solution for VMR, but I haven't looked at the DX10 specifications quite yet (are they even out yet?).
Blight - 04 06 06 - 14:31
Preliminary DX10 specifications are available in the latest editions of the DirectX SDK. You can begin writing DX10 apps, but the only way you can test them is to run them in Vista with refrast. I'd advise starting your test renders right before you go to lunch.
DX10 does not have any YCbCr format support. You are expected to use R8G8_B8G8_UNORM or G8R8_G8B8_UNORM for UYVY and YUY2, and to do your own color conversion. Unfortunately, at least as of Feb 2006 there is no definition of how the component upsampling is supposed to work. Given a post-SM3 shader architecture and virtualized video memory, though, doing your own conversion into a temporary buffer is no big deal.
Phaeron - 04 06 06 - 14:51
Erm, should this be fixed in Vdub? From the description of this problem, I would say it's actually a bug in the DWM, isn't it?
Thany - 04 06 06 - 16:44
Yes, I would say so as well... but if Microsoft ships with this bug, then I will have to work around it on my end.
Phaeron - 05 06 06 - 02:07
This has been confirmed as a bug in beta 2, so GetSurfaceDesc will work fine in later releases:
http://forums.microsoft.com/MSDN/ShowPos..obo - 29 06 06 - 09:04
Comment form
Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
