Previously we grab a run loop source and add a source with mode
kCFRunLoopDefaultMode. With this mode, it won't callback when context menu popup
(which needs the NSEventTrackingRunLoopMode), then screen capture can't get
refreshed frame with context menu until the context menu is gone.
The fix is to use kCFRunLoopComonModes, which includes default,modal and event
tracking modes by default.
BUG=chromium:697780
Review-Url: https://codereview.webrtc.org/2732393003
Cr-Commit-Position: refs/heads/master@{#17171}
DisplayStream refresh rects are in display coordinates. When the whole screen is
being captured, the coordinates passed to the ScreenCapturerHelper need to be in
screen coordinates. This CL translates display coordinates to screen
coordinates for whole screen capture.
BUG=chromium:699672
Review-Url: https://codereview.webrtc.org/2740823002
Cr-Commit-Position: refs/heads/master@{#17153}
Previusly errors from XServerPixelBuffer::CaptureRect() were not always
handled, which results in a black frame returned from the capturer
instead of an error.
BUG=webrtc:7305
Review-Url: https://codereview.webrtc.org/2738513005
Cr-Commit-Position: refs/heads/master@{#17101}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 10000 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not significant impact the capturer
performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Original-Commit-Position: refs/heads/master@{#16984}
Committed: c4e9d210b3
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#17024}
Reason for revert:
Misses deps for RTC_HISTOGRAM in Chrome.
email sent separately.
Also see https://codereview.chromium.org/2725143004/.
Original issue's description:
> BlankDetectorDesktopCapturerWrapper to detect a blank DesktopFrame
>
> DXGI capturer highly depends on video adapter and its driver, as well as Windows
> itself. I recently found it cannot work on my virtualbox instance any more,
> which indicates it may not work well on some specific systems. What worse is,
> the APIs do not return a failure in such case.
>
> So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
> pixels in the frame returned by a DesktopCapturer implementation. If all the
> pixels selected are blank, this wrapper returns a failure. A typical usage is to
> combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
> and use GDI capturer in case of failure.
>
> Usually less than 500 pixels are checked, so the
> BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
>
> This change is expected to resolve bug 682112 in another dimension.
>
> BUG=682112
>
> Review-Url: https://codereview.webrtc.org/2709523003
> Cr-Commit-Position: refs/heads/master@{#16984}
> Committed: c4e9d210b3TBR=sergeyu@chromium.org,zijiehe@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=682112
Review-Url: https://codereview.webrtc.org/2726983005
Cr-Commit-Position: refs/heads/master@{#16993}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 500 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#16984}
A bug has been reported to complaint the ScreenCapturerWinDirectx cannot capture
the first frame, which is used in "Report an issue" page.
A simple solution here is to skip the first frame.
This change also removes the friend relationship between
DxgiDuplicatorController / DxgiAdapterDuplicator / DxgiOutputDuplicator, which
is not really necessary.
BUG=682112
Review-Url: https://codereview.webrtc.org/2703123002
Cr-Commit-Position: refs/heads/master@{#16815}
This is a trivial change to remove duplicate logic, i.e. fallback capturer, from
ScreenCapturerWinMagnifier.
BUG=webrtc:7215
Review-Url: https://codereview.webrtc.org/2704943002
Cr-Commit-Position: refs/heads/master@{#16781}
Update the year in copyright headers from 2016 to 2017, and also rename a
variable in FallbackDesktopCapturerWrapperTest to follow coding style.
BUG=webrtc:7205
Review-Url: https://codereview.webrtc.org/2706193005
Cr-Commit-Position: refs/heads/master@{#16759}
FallbackDesktopCapturerWrapper is a DesktopCapturer implementation, which owns
two DesktopCapturer implementations. If the main DesktopCapturer fails, it uses
the secondary capturer. The logic is now used in ScreenCapturerWinMagnifier, and
it can also be shared in ScreenCapturerWinDirectx to fallback to Gdi capturer on
privilege prompt or login screen.
BUG=684937
Review-Url: https://codereview.webrtc.org/2697453002
Cr-Commit-Position: refs/heads/master@{#16677}
This change adds a ResolutionChangeDetector to help dxgi components, say
DxgiDuplicatorController and DxgiTexture to detect resolution changes.
BUG=684162
Review-Url: https://codereview.webrtc.org/2682913002
Cr-Commit-Position: refs/heads/master@{#16654}
The tests need "x11/shared_x_display.h" which is not included when use_x11 is false and we're on linux.
The problem is:
screen_capturer_integration_test.cc
- requires ->
screen_drawer.h
- requires ->
screen_drawer_linux.cc
- requires ->
x11/shared_x_display.h
which is not included when use_x11 is false.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2684683003
Cr-Commit-Position: refs/heads/master@{#16529}
In order to implicit cast an lvalue to an rvalue when returning
from a function, the return type and type of variable in the return
statement previously had to be exactly the same. When this was not
the case, std::move was required. For instance, when returning a
std::unique_ptr<Derived> variable in a function with a
std::unique_ptr<Base> return type, std::move is required.
DR 1579 changed this, and allows for implicitly converting
to the return type, if the return type has a constructor(T&&), where
T is the type of the local variable being returned. DR 1579 was
implemented in GCC 5, but not in GCC 4.9 and below. By explicitly
qualifying the local variable with std::move, we allow for compiling
with GCC 4.9 and incur no performance penalty. The code is still
absolutely correct to the word of C++11.
BUG=chromium:682965
See also:
* https://bugs.gentoo.org/show_bug.cgi?id=600288
* https://stackoverflow.com/questions/22018115/converting-stdunique-ptrderived-to-stdunique-ptrbase#comment33375875_22018521
* http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3833.html#1579
Review-Url: https://codereview.webrtc.org/2642053003
Cr-Commit-Position: refs/heads/master@{#16175}
Bulk of changes done using
git grep -l 'RTC_DCHECK(false)' | \
xargs sed -i 's/RTC_DCHECK(false)/RTC_NOTREACHED()/'
peerconnection.cc also used RTC_DCHECK(false && "msg") in two places,
which were updated manually.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2623313004
Cr-Commit-Position: refs/heads/master@{#16026}
This moves some GN check configurations out of .gn to individual
targets.
The now checked target is:
"//webrtc/modules/desktop_capture/*"
BUG=webrtc:6828
NOTRY=True
Review-Url: https://codereview.webrtc.org/2593713002
Cr-Commit-Position: refs/heads/master@{#15725}
The CGDisplayStream API returns rects in physical pixel coordinates, not
Density-Independent Pixel coordinates. The code was incorrectly re-applying the
dip_to_pixel scaling.
BUG=chromium:675490
Review-Url: https://codereview.webrtc.org/2588973002
Cr-Commit-Position: refs/heads/master@{#15720}
ScreenCapturerWinGdi randomly returns black frames in test environment. The root
cause is still unknown, so change ScreenCapturerWinGdi tests into MANUAL mode to
execute in test environment, but unblock other developers. We can eventually get
a failure ratio and more samples for debugging.
BUG=webrtc:6666, webrtc:6843
Review-Url: https://codereview.webrtc.org/2564173002
Cr-Commit-Position: refs/heads/master@{#15518}
GDI capturer may randomly return a blank frame. So this change enables tests for
Linux / DirectX capturer / magnifier capturer.
BUG=webrtc:6666
Review-Url: https://codereview.webrtc.org/2559583002
Cr-Commit-Position: refs/heads/master@{#15489}
BitBlt returns a BOOL value, which should be taken care in ScreenCapturerWinGdi.
Meanwhile, this change also replaces assert() / abort() with RTC_DCHECK() /
RTC_CHECK() / RTC_NOTREACHED().
This change cannot fix the bug, the reason of the issue is still unknown, but it
is still the right thing to do.
In ScreenCapturerIntegrationTest, each frame will be captured at most 600 times.
Since the test case fails, which means the ScreenCapturerWinGdi consistently
returns a white frame for 600 times under a certain state. With this change,
instead of returning white frame, ScreenCapturerWinGdi will return a temporary
error. But I do not think a ScreenCapturerWinGdi can automatically recover by
retrying.
BUG=webrtc:6843
Review-Url: https://codereview.webrtc.org/2553353002
Cr-Commit-Position: refs/heads/master@{#15465}
A trivial change to remove a deprecated comment.
BUG=chromium:314516
Review-Url: https://codereview.webrtc.org/2553283002
Cr-Commit-Position: refs/heads/master@{#15454}
To support rotation in DirectX capturer, several other changes are also
required.
1. Removing AddRect in RotateDesktopFrame, this is a performance improvement.
DxgiOutputDuplicator creates a rotated DesktopRegion, which can be directly
add to updated_region.
2. DxgiOutputDuplicator::SourceRect() is not accurate, the rectangle in source
is controlled by |offset| or |rotation_| + |offset|, instead of desktop_rect().
3. The |region| in DxgiTexture::CopyFrom() is not accurate. It needs an
unrotated DesktopRegion which offsets by |offset| instead of desktop_rect(). To
avoid generating both rotated and unrotated updated_region, this parameter has
been removed. This impacts DxgiTextureStagning performance a little bit (1.5ms).
Refer to bug for details.
BUG=webrtc:6646
Review-Url: https://codereview.webrtc.org/2530303002
Cr-Commit-Position: refs/heads/master@{#15308}
This change adds RotateDesktopFrame(), RotateRect(), RotateSize(),
ReverseRotate() functions, so an implementation can use these free functions to
rotate and copy pixels from one DesktopFrame to another at the same time.
This is the first part of the change to support rotation in DirectX capturer. In
a coming change, these functions will be used in DxgiOutputDuplicator to do the
rotation and copying.
Background,
DirectX APIs always return unrotated data buffer, so we need to rotate it to
match the user-selected rotation. What worse is except for the data buffer,
other variables return by these APIs are all rotated, e.g. output size, monitor
position. So we will eventually not be able to capture the rotated monitors,
because we cannot set their position and size correctly. Though
DXGI_OUTDUPL_DESC provides a DXGI_MODE_ROTATION enumeration to indicate the
output rotation, it does not provide a simple way to rotate an IDXGIResource,
which is the only thing we can get from duplication APIs. A typical user case
here is to use a matrix to transform the IDXGIResource and render it to a
surface. But since we do not render the IDXGIResource at all, we need to
manually rotate it.
BUG=314516
Review-Url: https://codereview.webrtc.org/2500883004
Cr-Commit-Position: refs/heads/master@{#15205}
ScreenCapturerIntegrationTest is flaky on Windows systems due to some unknown
reason. But it's do easily impacted by the environment, so this change adds more
logging (entire screenshot) to help debugging.
Meanwhile, this change also includes a nice-to-have change in ScreenDrawerWin to
always bring the window to front in each WaitForPendingDraws() function call. I
cannot quite tell whether this change can help to resolve the issue, but it is
worth trying.
BUG=webrtc:6666
Review-Url: https://codereview.webrtc.org/2492723002
Cr-Commit-Position: refs/heads/master@{#15158}
The old API CGScreenRegisterMoveCallback returned update rects in desktop
coordinates [secondary display has an origin != 0,0]. The new CGDisplayStream
API returns update rects in display coordinates [origin == 0,0]. Translating the
update rect based on the display's position on the desktop is now incorrect.
BUG=webrtc:6702
Review-Url: https://codereview.webrtc.org/2496413002
Cr-Commit-Position: refs/heads/master@{#15092}
In DxgiOutputDuplicator, we need to convert between a monitor based coordinate
and a entire screen based coordinate. i.e. Copying an updated area from a
monitor (an output in DirectX API) to the entire screen frame (DesktopFrame).
But DxgiOutputDuplicator always assumes the coordinate is based on screen frame.
So we only need to convert a rectange in updated_region to monitor based
coordinate when copying data from texture_. But in last_frame_, the data are
always based on screen coordinate.
So fixes are both required in line 167 and line 180. In the previous one, we do
not need to convert the DesktopRect, which is already screen based, into screen
based coordinate. In the late one, we do not need to convert the DesktopRect at
all. So after these two changes, DxgiOutputDuplicator::TargetRect() function can
be removed.
Flickers of DirectX capturer can happen on any devices, but a virtual machine
can easily reproduce it. While on a regular high performance machine, it's
harder, but not totally impossible, to reproduce the issue.
BUG=314516
Review-Url: https://codereview.webrtc.org/2495143002
Cr-Commit-Position: refs/heads/master@{#15075}
This is a trivial change to remove MockScreenCapturerCallback, and use
MockDesktopCapturerCallback to replace it.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2494013003
Cr-Commit-Position: refs/heads/master@{#15047}
A tiny but critical change to avoid a crash failure in DirectX capturer.
A good news is this failure is caught by ScreenCapturer integration tests.
BUG=314516
Review-Url: https://codereview.webrtc.org/2494893002
Cr-Commit-Position: refs/heads/master@{#15046}
The old CroppingWindowCapturer::Create() function returns a raw pointer, which
cannot explain the ownership.
So this change adds a CreateCapturer() function to return a unique_ptr.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2496993003
Cr-Commit-Position: refs/heads/master@{#15045}
This change removes ScreenCapturer and WindowCapturer from WebRTC.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2490063002
Cr-Commit-Position: refs/heads/master@{#15033}
This change removes references of ScreenCapturer and WindowCapturer from WebRTC.
So after this change, ScreenCapturer and WindowCapturer classes can be entirely
removed.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2489943004
Cr-Commit-Position: refs/heads/master@{#15006}
This is a trivial but dangerous change to remove X11/Xlib.h out of
shared_x_display.h. Since we do not have a strict and automatically
Include-What-You-Use rule, I cannot quite tell whether any Chromium source files
wrongly assume X11/Xlib.h will be included through shared_x_display.h. We can
fix the breaks in Chromium after this change has been failed to integrate to
Chromium.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2482963003
Cr-Commit-Position: refs/heads/master@{#14987}
