Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
 
Other projects
   Altirra

Archives

Blog Archive

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:

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.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.