¶DirectDraw rendering glitches with multiple displays
It's been reported to me that an odd thing happens on systems with multiple monitors where VirtualDub will repeatedly lock up the system with display flashes whenever the display panes overlap the second monitor. I saw this in person once, but unfortunately wasn't in a position to debug it, and only recently have been able to recreate it on my debug station. The circumstances where this occurs are:
- DirectDraw display mode is enabled (default).
- Direct3D/OpenGL display mode is not enabled (default).
- Some part of a display pane overlaps a non-primary monitor.
I think another condition is "you have an NVIDIA video card," but a sample size of two with all NVIDIA cards isn't conclusive. Might be XP-only, too.
When this happens, the display will flash and the entire system locks up for about half a second every time VirtualDub tries to repaint the panes. Joy. The workaround is to change the display options in Options > Preferences > Display, and either disable DirectX support (slow) or enable Direct3D mode (preferred).
I traced through this a bit and the entire effect occurs in IDirectDrawSurface3::Blt(). There doesn't appear to be anything special about this call except the destination rectangle. I managed to reproduce this effect on at least two other DirectDraw-based applications, unfortunately, so that means I'm likely in workaround territory rather than fix territory. I also wasn't able to break into the debugger during the call to find out what exactly was locking everything up since the debugger was also frozen, which means resorting to CDB or a remote kernel-mode debugger. If I can't figure any other solution, I'll probably just manually clip the destination and source rectangles to the primary monitor. VirtualDub doesn't currently instantiate a DirectDraw context per adapter and so it can't render on the secondary monitor that way anyway, and clip precision isn't an issue because the DirectDraw runtime already only clips to integer precision -- the lack of subpixel precision is why weird artifacts appear when you drag another window on top of a DirectDraw-based application that's doing a stretchblt.