I ran into a strange problem trying to combine a tab control with a list view.

Tab controls are among the weirder of the controls in the Win32 common controls suite. A tab control lets the user select between a number of tabs, and the program then changes information displayed based on the selected tab. If you've used another UI system, you might expect the pages to be parented to the tab, but not in Win32 -- if you try to do that you quickly discover that all of your child controls break, because all of their notifications now go to the tab control. What you have to do instead is overlap the controls corresponding to the page on top of the tab control instead, with all of them parented to the dialog. This doesn't look any different to the user, but it has lots of implications for the way that the UI code is structured.

One of the annoying problems with Win32 UI is that overlapping controls in general are bad news. In theory it's not too hard of a problem to solve in a windowing system, as you just have to and dutifully paint all windows affected by any invalidation in the correct order. In practice, I've found that Windows doesn't quite get this right, and you get into many corner case redrawing problems. This is compounded by buttons, which (a) render transparent and require that the dialog itself supply the background erase, and (b) must overlap other controls when used in group box mode. Therefore, you can end up in a number of cases where a resizable dialog doesn't quite redraw correctly when resized.

In this case, the problem was a bit more severe:

Both images are of a dialog containing a tab control with a list view on top of it, created fresh in the VC++ dialog editor. The first image is how it initially displays; the second one is after changing a column width. Yuck. It was actually worse than I can show in a static image, as sometimes the entire list view would disappear.

My first thought was, oh great, the tab control is drawing over the list view. Indeed, that was the case, but according to Spy++ WS_CLIPSIBLINGS was set on the tab control, and no amount of style fiddling seemed to fix the problem. The WS_CLIPSIBLINGS flag is supposed to exclude other child windows from that window's paint, which in this case would prevent the tab control from drawing over the list view. Well, after subclassing the tab control and doing some experiments, it turns out that the documentation is both absolutely correct and still misleading. WS_CLIPSIBLINGS does indeed exclude other overlapping child windows during painting (WM_PAINT). What it does not do is exclude other windows during the background erase (WM_ERASEBKGND)! Tab controls defer to DefWindowProc() for the latter message, which dutifully does a FillRect() with the class background brush of COLOR_3DFACE... with no clip region. Owww.

I ended up "fixing" the problem by subclassing the tab control, intercepting WM_ERASEBKGND, and calling ExcludeClipRect() with the rectangle of the list view. I still can't believe that WS_CLIPSIBLINGS doesn't clip the erase operation, though, because that seems like a gaping hole in the implementation. Actually, it doesn't surprise me too much -- frankly, many parts of USER are broken as designed -- but it still bugs me because checked against the Wine source code, which appears to use the same clip region for erase and paint operations. If anyone knows of an additional condition for WM_CLIPSIBLINGS to react in this manner, I'm curious.

A while ago, I added the screen capture driver to VirtualDub, which allows you to use capture mode in order to capture the screen instead of from an external video source. One of the special hacks in this module was OpenGL capture mode, which used a quirk in the definition of OpenGL front buffer rendering to achieve hardware accelerated screen capture -- in particular, using the graphics card to do scaling, color conversion, and change detection. Unfortunately, starting with Windows Vista, or more precisely WDDM, this doesn't work anymore due to front buffer redirection. Therefore, the only way you can capture the screen is by turning off OpenGL mode in Video > Video Source, which disables all of the neat features.

Recently, I had to capture the screen in Windows 7, and I was pleasantly surprised by the speed. When OpenGL capture mode is disabled, the screen capture driver works by simply doing a BitBlt() from the screen (i.e. GetDC(NULL)) into a DIB section and then reading that out. On Windows XP, this is dog slow and unusable for capture at any real size and frame rate. It appears that on Windows 7 there has been some major optimization put into this and the BltBlt operation is much faster, as I was able to pull 1024x768x32 at 20 fps. It's still not quite as fast as a hardware accelerated downscale + YCbCr conversion, but it's definitely usable. This might be fast in Vista as well, but I can't tell as I don't even bother having an install of that OS anymore. The cursor blinks a lot during the capture, but VirtualDub has to manually redraw the cursor anyway so this doesn't matter in the output video.

In any case, it's good that at least some 2D operations are getting faster again....