commit 366ac4d84e67d677d7a851d5796369e0b61cf87c
author Bryan Ferguson <bryanf@microsoft.com> Fri Jul 26 17:45:01 2019
committer Commit Bot <commit-bot@chromium.org> Sat Jul 27 00:50:03 2019
tree f56dba714453b004050eac48da3a93de1f18b62e
parent fd6d8d7129ee1cdf81850ac71f6cf4452cb1f65c

Allow use of CroppingWindowCapturer via CreateWindowCapturer

Currently, apps using WebRTC for window capture only get the benefits of
using CroppingWindowCapturer on Windows (described below) after changing
calls to DesktopCapturer::CreateWindowCapturer to instead call
CroppingWindowCapturer::CreateCapturer. This change adds a new flag to
DesktopCaptureOptions to allow opting in to the faster capture-screen-
and-crop path via the older & more discoverable API.

Benefits of using CroppingWindowCapturer's capture-screen-and-crop path
when possible:
1) It's significantly faster, up to ~36ms/frame (~160x) faster than the
capture-window-contents path in my testing (more details are in the
bug). This difference increased with the recent fix for
https://crbug.com/webrtc/10734 .
2) It allows capture of menus & tooltips (plus dialogs if
https://crbug.com/webrtc/10767 is fixed), partially mitigating
https://crbug.com/980864 .

Downsides of using it:
1) It may inadvertently capture occluding windows that aren't detected
properly, e.g. some system UI: https://crbug.com/webrtc/10835 .
2) It may capture some neighboring regions when moving/resizing the
captured window.

The new flag is not enabled by default, so the default behavior is
unchanged. This could perhaps be revisited after addressing
https://crbug.com/webrtc/10835 .

Bug: webrtc:10825
Change-Id: Ib77e5facc7240c5df311fe1fe204d0d8ea22a96a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146823
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28695}