I noticed this problem while re-working some performance tests.  In one case, I measured the renderer for a tab had executed draws almost exactly 24 FPS (over a 10-second window), while the number of frames captured by tab capture was almost 26 FPS.

Turns out the root cause was due to the tab capture indicator in the browser tab strip UI: For the first 3 seconds of the run, there were extra browser composites to animate this indicator (the flashing on-off animation).  These were causing DelegatedFrameHost::WillDrawSurface() to be called because the surface representing the tab content area was a child surface of the one representing the entire browser window.

The solution to this is quite simple: Simply do not attempt capture when the damage region of the surface is empty.