Per discussion in
https://chromium-review.googlesource.com/c/external/webrtc/+/641814, the
behavior of IsWindowOnScreen() functions when native APIs fail should be
flipped. I.e. window is *not* on screen if OS cannot find it.
Bug: chromium:758554
Change-Id: Ife449a5261fcd89c37595e29a0b1802fcf3c42a5
Reviewed-on: https://chromium-review.googlesource.com/644290
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19617}
GetCroppingWindowRect() is too generic and easy to be misused. For example, in
WindowCapturerWin, it's used to calculate the DesktopRect of the target window,
which is inaccurate. See the screenshot in the bug, it wrongly crops borders on
Windows 8+.
So GetCroppingWindowRect() should be removed eventually, the logic should be
placed in CroppingWindowCapturerWin. But since it's still used in the deprecated
logic in MouseCursorMonitorWin, I would prefer to remove this function after
MouseCursorMonitor improvement has been finished.
But before that, WindowCapturerWin should use GetWindowDrawableRect() instead of
GetCroppedWindowRect() to avoid the wrongly cropping behavior on Windows 8+.
Bug: webrtc:8157
Change-Id: I012b663dced8105623c563dbe55ffcb8d7f17f75
Reviewed-on: https://chromium-review.googlesource.com/642092
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19614}
As discussed in change
https://chromium-review.googlesource.com/c/external/webrtc/+/634043, the name of
IsWindowMinimized() functions is too confusing. IsWindowOnScreen() is preferred,
since it describes the behavior of the functions more accurately.
This change does not flip the default behavior of these functions to avoid a
behavior change. TODO has been added; and the flipping will happen in a
following change.
Bug: chromium:758554
Change-Id: I009c0fa57142756e5c83f76b2a3561253db1b67f
Reviewed-on: https://chromium-review.googlesource.com/641814
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19613}
also C++ code (see https://bugs.chromium.org/p/webrtc/issues/detail?id=7743
for more information).
To achieve this we have created 2 targets (desktop_capture_objc and
desktop_capture_generic) and desktop_capture will act as a proxy between these
targets (this way we can avoid a circular dependency between
desktop_capture_generic and desktop_capture_objc).
BUG=webrtc:7743
Review-Url: https://codereview.webrtc.org/2989053002
Cr-Commit-Position: refs/heads/master@{#19607}
directives in our DEPS files are not needed anymore.
Includes from webrtc/rtc_base are also whitelisted in webrtc/DEPS
so we don't have to whitelist it in all the others DEPS files.
BUG=webrtc:7634
NOTRY=True
Review-Url: https://codereview.webrtc.org/3006583002
Cr-Commit-Position: refs/heads/master@{#19601}
This change adds one temporary use_desktop_relative_cursor_position_ flag in
DesktopAndCursorComposer. It's automatically set according to the consturctor
used.
When the flag is true, DesktopAndCursorComposer uses the newly added
MouseCursorMonitor::Callback::OnCursorPosition(), which is the absolute position
of the cursor in the full desktop coordinate, and DesktopCapturer::IsOccluded()
to decide whether the mouse cursor should be drawn on the DesktopFrame.
When the flag is false, the behavior of DesktopAndCursorComposer is unchanged.
This flag will be removed together with the deprecated constructor of
DesktopAndCursorComposer.
Currently the new DesktopAndCursorComposer constructor is not used, so no
behavior change is expected.
Bug: webrtc:7950
Change-Id: I7235e32fa325a21c4a2594613764a9f81d76dfbc
Reviewed-on: https://chromium-review.googlesource.com/641075
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19592}
XWindowAttributes.x and y are in the coordinate of the parent window, so
XTranslateCoordinates() should be used to do the translation.
Meanwhile this change reduces the scope of the XErrorTrap in GetWindowList()
function to ensure the callback can use other XErrorTrap to cover other X
function calls.
Bug: webrtc:7950
Change-Id: I520227b11704c5a0cb665d9de86925ed4e86540d
Reviewed-on: https://chromium-review.googlesource.com/639590
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19591}
In this change,
bool DesktopCapturer::IsOccluded(const DesktopVector& pos);
is added to DesktopCapturer interface. This function returns true if the |pos|
is hidden by other elements on the display.
The function expects to return false for ScreenCapturer implementations:
everything is visible on the screen.
In WindowCapturer implementations, WindowFinder is expected to be used to help
detect the WindowId under |pos|. If the window_id_ equals to the window id
returned by WindowFinder, this function returns false.
To ensure the correct coordinate is used, a comment is also added to
WindowFinder::GetWindowUnderPoint() function. Considering it's used only in
desktop_capture module, using system coordinate is simpler.
Bug: webrtc:7950
Change-Id: I8ac4fbd5f4a612388f1593907805cfb2c359f70f
Reviewed-on: https://chromium-review.googlesource.com/636784
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19590}
If the content area of a window is not covered by the content area of another
window, we do not treat them as overlapping. This can fix the issue that two
fullscreen windows cover each other, or a fullscreen window is covered by the
shadow effect of task bar.
Bug: chromium:741770
Change-Id: I92dc636bc8445d50b00390cf3332695f69daf9c6
Reviewed-on: https://chromium-review.googlesource.com/628244
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19532}
WindowCapturerWin wrongly calculate the image size if the application it target
does not support high DPI. It causes part of the output frame black. See bug for
details.
Bug: webrtc:8112
Change-Id: I33c66dfa977ec08a29c56ff86ae37320b1459c87
Reviewed-on: https://chromium-review.googlesource.com/634383
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19531}
A crash may randomly happen in IsWindowMinimized(), the potential reason is that
|on_screen| is not retrieved from |window| with kCGWindowIsOnScreen property. So
add a == NULL check before executing CFBooleanGetValue().
Bug: chromium:758554
Change-Id: I25ad1ddbb21ec049ef237e55a8d25156bcd982c7
Reviewed-on: https://chromium-review.googlesource.com/634043
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19527}
The original change https://chromium-review.googlesource.com/c/575315 and
https://chromium-review.googlesource.com/c/590508 have not been well-considered.
So this change reverts part of two changes and adds a
DesktopFrame::set_top_left() function
A DesktopFrame usually contains a very large chunk of memory, which should be
reused as much as possible to reduce the memory allocations. The size of the
memory usually controls by the DesktopFrame::size(). So it's reasonable to const
DesktopFrame::size_: changing it is wrong if the underly buffer is not large
enough.
But DesktopFrame::top_left() is a different story, same as capturer_id,
capture_time_ms and other information in the DesktopFrame, it can be changed to
any value without needing to reconstruct a DesktopFrame instance. So instead of
adding it to the constructor, a DesktopFrame::set_top_left() is added to adjust
the top-left of the DesktopFrame in the entire display coordinate.
After adding DesktopFrame::set_top_left(), we have five variables in a
DesktopFrame which is not initialized in the constructor. For any kind of
wrapper DesktopFrame, say, SharedDesktopFrame and CroppedDesktopFrame, they
needs to copy these five variables after constructing themselves. This is not
convenient and easily to be broken if an implementation forgot to copy them.
So DesktopFrame::MoveFrameInfoFrom() and DesktopFrame::CopyFrameInfoFrom() are
added to the DesktopFrame to help derived classes to copy or move these
variables in one function call.
The difference between MoveFrameInfoFrom() and CopyFrameInfoFrom() is that the
former one uses DesktopRegion::Swap() to move the DesktopRegion from the source
DesktopFrame to this instance, while the later one uses copy-operator to copy
the DesktopRegion from the source DesktopFrame.
So CopyFrameInfoFrom() is usually used when sharing a source DesktopFrame with
several clients. I.e. the source DesktopFrame should be kept unchanged. For
example, BasicDesktopFrame::CopyOf() and SharedDesktopFrame::Share().
On the other side, MoveFrameInfoFrom() is usually used when wrapping a
DesktopFrame. E.g. CroppedDesktopFrame and DesktopFrameWithCursor.
Bug: webrtc:7950
Change-Id: I8b23418960fb681d2ea1f012d1b453f514da2272
Reviewed-on: https://chromium-review.googlesource.com/622453
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19504}
Windows cannot capture contents on VMs hosted in GCE, disable them to unblock
GCE hosting.
Bug: webrtc:8153
Change-Id: Iacdce15008cc092dce36d08b1d5565bbaa5def1f
Reviewed-on: https://chromium-review.googlesource.com/634083
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19502}
We are still using cropping window capturer even the window is out of the screen.
See the bug for details.
Bug: webrtc:8134
Change-Id: I5161b1a17a3a1f8244697eea5eb78975be6908f9
Reviewed-on: https://chromium-review.googlesource.com/627338
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19474}
On Windows a window may be covered by its own child window. So this change also
detects child windows by using EnumChildWindow().
The tooltip or context menu of the child window still cannot be detected after
this change. See bug for details.
Bug: webrtc:8062
Change-Id: I8455a9206d6a1d9da61013ac9debba4d3edae7d8
Reviewed-on: https://chromium-review.googlesource.com/619728
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19457}
This change renames ScreenDrawerLockLinux into ScreenDrawerLockPosix and shares
it with Mac OSX.
Bug: webrtc:7950
Change-Id: Ib141781d2c35bfda0d6f9458fff235adbb643280
Reviewed-on: https://chromium-review.googlesource.com/607688
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19393}
WindowUnderPoint have different signatures on different platforms, which should
be abstract as an interface.
So this change adds a WindowFinder interface to replace WindowUnderPoint free
function. Meanwhile, this change also includes the implementation of
WindowFinderX11 for X11.
Bug: webrtc:7950
Change-Id: I897a50d4033e713b339b6b6f48b5dbbe601e8db0
Reviewed-on: https://chromium-review.googlesource.com/611745
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19375}
This change implements GetWindowList() on X11. WindowCapturerLinux and
GetWindowUnderPoint() can share the logic of this function.
Bug: webrtc:7950
Change-Id: Ida746840d6f51d31e0470e5ae4955b6f5a4cfaf2
Reviewed-on: https://chromium-review.googlesource.com/606560
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19314}
That way, the debug printout will tell us which of x and y that was false.
BUG=none
Review-Url: https://codereview.webrtc.org/2988153003
Cr-Commit-Position: refs/heads/master@{#19297}
During window capture on Windows 10, if the selected window is minimized,
ShouldUseScreenCapturer() still thinks it's on top and continue to do a
screencapture which is meaningless.
This cl will set |.is_top_window| with false to minimized window,then we
can skip doing any capture to it.
BUG=chromium:568835
Review-Url: https://codereview.webrtc.org/2997493002
Cr-Commit-Position: refs/heads/master@{#19276}
A crash has been randomly detected across different versions. The NSImage
crashes the binary in its lockFocusFlipped() function. The suspicious issue is
that NSCursor::image() returns an invalid NSImage.
BUG=chromium:752036
Review-Url: https://codereview.webrtc.org/2993173003
Cr-Commit-Position: refs/heads/master@{#19273}
WindowUnderPoint() is a platform independent function to return the id of the
first window in z-order under a certain DesktopVector. It equals to
GetAncestor(WindowFromPoint(point), GA_ROOT)
on Windows.
This CL includes the change to Windows / Mac OSX only to control the size in a
reasonable range. Implementation for Linux will be added in a coming change.
Bug: webrtc:7950
Change-Id: I57e423294fc8aeaa12d05cb626a1912240b2d4d0
Reviewed-on: https://chromium-review.googlesource.com/595022
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19263}
This reverts commit ae1532a214bb949b3e2b0659293b5f6bab104598.
Reason for revert: It is blocking the WebRTC roll into Chromium (see: https://chromium-review.googlesource.com/c/599707).
Affected build:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_compile_dbg_ng/builds/469708
Original change's description:
> Track recreation of DxgiTextureStaging
>
> I am not sure memcmp is the right tool to compare two D3D11_TEXTURE2D_DESC
> instances. So the staging texture may be recreated for each frame, which hurts
> the performance.
>
> Bug: webrtc:8046
> Change-Id: I60a94f468599b23dec168de55c9bc8c787ab9b7d
> Reviewed-on: https://chromium-review.googlesource.com/592088
> Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
> Commit-Queue: Zijie He <zijiehe@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#19193}
TBR=jamiewalch@chromium.org,zijiehe@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:8046
Change-Id: I57951e22be6926bcde81cdac3ca64cab9fb43338
Reviewed-on: https://chromium-review.googlesource.com/599867
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19232}
During window capturing, if the target window is minimized, OSX/Windows
will return a 1x1 frame and then webrtc knows to replace it with a black
frame. Let's do same on Linux too.
BUG=568840
Review-Url: https://codereview.webrtc.org/2989233002
Cr-Commit-Position: refs/heads/master@{#19224}
This change adds constructors for all DesktopFrame inheritances to pass in
DesktopRect instead of DesktopSize.
Because the newly added constructors and DesktopFrame::top_left() function are
not actively used, this change should have no logic impact.
Bug: webrtc:7950
Change-Id: If78187865c991211dfc28d3723403ce6e6fe0290
Reviewed-on: https://chromium-review.googlesource.com/590508
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19204}
I am not sure memcmp is the right tool to compare two D3D11_TEXTURE2D_DESC
instances. So the staging texture may be recreated for each frame, which hurts
the performance.
Bug: webrtc:8046
Change-Id: I60a94f468599b23dec168de55c9bc8c787ab9b7d
Reviewed-on: https://chromium-review.googlesource.com/592088
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19193}
resolution_tracker_ should always represent the size of the DxgiFrame::frame_.
So it should not be actively reset.
Bug: webrtc:8045
Change-Id: I0b4d70ea69e4c2febfa369de50b555287c41fd99
Reviewed-on: https://chromium-review.googlesource.com/592248
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19192}
DxgiTexture now does not rely on a fixed resolution, so the ResolutionTracker
can be removed from it.
This change does not have logic impact, the upper component
(DxgiDuplicatorController) always reinitializes itself once the screen
resolution changes. And this check is also a legacy one: DxgiFrame now can take
care of the resolution change itself without needing to return false in
DxgiTexture.
Bug: webrtc:8044
Change-Id: I3ad9ce175f2bc9bf03b0a3985efa2681aa55d14b
Reviewed-on: https://chromium-review.googlesource.com/592247
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19191}
ResolutionChangeDetector now does not update its internal state. There is no
impact because Reset() is always actively called.
So this change renames ResolutionChangeDetector to ResolutionTracker, and rename
the IsChanged() function into SetResolution(), which returns true if a
replacement happened. Internally it always records the latest DesktopSize.
Customers of this class can still use SetResolution() function to check whether
a DesktopSize change happened.
Bug: webrtc:8038
Change-Id: I6d25f3dd2d0567219a82b6688bf3e08560c8b0af
Reviewed-on: https://chromium-review.googlesource.com/587405
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19184}
CreateCroppedDesktopFrame() does not need to create a CroppedDesktopFrame if the
size won't change.
Bug: webrtc:8039
Change-Id: Ie6789a4b473b69bced94c4a25a68f1da6bb3510e
Reviewed-on: https://chromium-review.googlesource.com/587808
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19163}
We should record the number of fallbacks and blank frames.
Bug: webrtc:8040
Change-Id: I92e7b7d7b4664fee6d6bd636609e80e532aa4bd4
Reviewed-on: https://chromium-review.googlesource.com/587688
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19161}
This change returns translated position in the newly added overload
MouseCursorMonitor::Callback::OnMouseCursorPosition(DesktopVector) callback.
Meanwhile it also reduces the duplicate logic in Windows capturer
implementations. So except for the deprecated logic in MouseCursorMonitorWin,
all GetSystemMetrics() function calls are merged into GetScreenRect(),
GetFullscreenRect() and GetFullscreenTopLeft() functions.
Bug: webrtc:7950
Change-Id: Ic2a85a80b6947367bdd20d8f96f11e0f5c269006
Reviewed-on: https://chromium-review.googlesource.com/581951
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19157}
Current implementation requires MouseCursorMonitor to understand the SourceId of
a DesktopCapturer implementation. But SourceId has different meanings across
various DesktopCapturer implementations. So this change decouples the
MouseCursorMonitor from DesktopCapturer, i.e. it does not need to know
DesktopCapturer anymore, instead it always returns the absolute position of the
mouse cursor. In DesktopAndCursorComposer, it can use the newly added
DesktopFrame::top_left() to decide the relative position of mouse cursor and the
DesktopFrame.
Bug: webrtc:7950
Change-Id: Idfbde5cb0f79ff0acf4ad1e9a0ac5126f1bb2e98
Reviewed-on: https://chromium-review.googlesource.com/575315
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19115}
All downstream code have been updated to the new location.
In PRESUBMIT.py:
* Remove webrtc/rtc_base from CPP_BLACKLIST
* Add webrtc/rtc_base to LEGACY_API_DIRS
Fix some duplicated paths in
webrtc/modules/audio_processing/test/conversational_speech/BUILD.gn
BUG=webrtc:7634
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2976293002
Cr-Commit-Position: refs/heads/master@{#19094}
This change ensures DirectX capturer to return the same ScreenId as GDI capturer
for each monitor. So MouseCursoeMonitor can work correctly with the DirectX
capturer.
This is a temporary fix of webrtc:7950.
Bug: webrtc:7950
Change-Id: Icd3f40556701811c21c773a39260a74db43979f3
Reviewed-on: https://chromium-review.googlesource.com/571101
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19079}
IsCurrentSessionSupported() is useful to decide whether Windows version should
be used to evaluate the capability of DirectX capturer on the system.
Bug: 741926
Change-Id: Iaaf6011a9e464d7cf5e7dda097007778c73953e0
Reviewed-on: https://chromium-review.googlesource.com/571378
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19060}
Both DXGI_OUTPUT_DESC and DISPLAY_DEVICE contain the DeviceName, which may be
able to map a DirectX screen id with the GDI screen id.
So this change exports the field from both DirectX and GDI implementations.
BUG=webrtc:7950
Review-Url: https://codereview.webrtc.org/2971393002
Cr-Commit-Position: refs/heads/master@{#19010}
The root cause is when a DxgiContext is reseted, it has not been correctly
cleared from DxgiOutputDuplicator. So during next CaptureFrame() function call,
DxgiOutputDuplicator will spread the context change to a deleted instance.
BUG=741252
Review-Url: https://codereview.webrtc.org/2975103002
Cr-Commit-Position: refs/heads/master@{#18992}
All downstream code have been updated to the new location.
In PRESUBMIT.py:
* Remove webrtc/rtc_base from CPP_BLACKLIST
* Add webrtc/rtc_base to LEGACY_API_DIRS
Fix some duplicated paths in
webrtc/modules/audio_processing/test/conversational_speech/BUILD.gn
BUG=webrtc:7634
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2973183002
Cr-Commit-Position: refs/heads/master@{#18948}
On Windows8/10, we prefer cropping desired window out from a whole screen
capture due to some reasons. The problem is Win10 has an invisible border
around the window. If we leave the border, it will expose background a bit.
This cl is about to always remove the border of desired window on Win8/10.
This will help a lot to capturing still windows during window sharing.
This cl still can't handle the background exposure issue when you move the
target window around during capturing. More investigation is needed.
BUG=chromium:737278
Review-Url: https://codereview.webrtc.org/2973853002
Cr-Commit-Position: refs/heads/master@{#18921}
