Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
CL partially auto-generated with:
git grep -l "\bassert(" | grep "\.[c|h]" | \
xargs sed -i 's/\bassert(/RTC_DCHECK(/g'
And with:
git grep -l "RTC_DCHECK(false)" | \
xargs sed -i 's/RTC_DCHECK(false)/RTC_NOTREACHED()/g'
With some manual changes to include "rtc_base/checks.h" where
needed.
A follow-up CL will remove assert() from Obj-C code as well
and remove the #include of <assert.h>.
The choice to replace with RTC_DCHECK is because assert()
is because RTC_DCHECK has similar behavior as assert()
based on NDEBUG.
This CL also contains manual changes to switch from
basic RTC_DCHECK to other (preferred) versions like
RTC_DCHECK_GT (and similar).
Bug: webrtc:6779
Change-Id: I00bed8886e03d685a2f42324e34aef2c9b7a63b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224846
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34442}
Enumerating windows owned by the current process on Windows has some
complications due to the GetWindowText*() APIs potentially causing a
deadlock. The APIs will send messages to the window's message loop, and
if the message loop is waiting on this operation we will enter a
deadlock.
I previously put in a mitigation for this [1] which brought the
incidence rate down by an order of magnitude, but we are still seeing
this issue fairly frequently.
So, I've added DesktopCaptureOption enumerate_current_process_windows
which allows consumers to avoid this issue completely by ignoring
these potentially problematic windows.
By default the flag is set to true which equates with the current
behavior, consumers can set the flag to false to get the new behavior.
I've also updated all the capturers that enumerate windows on Windows
to respect the option.
[1] https://webrtc-review.googlesource.com/c/src/+/195365
Bug: chromium:1152841
Change-Id: I0e0d868957d6fbe1e607a440b3a909d005c93ccf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219380
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#34191}
* Add OpenOfficeApplicationHandler for MacOS and MS Windows.
* List of available sources for FullScreenWindowDetector on MacOS can include a window with empty title along with titled window for one application.
* List of available sources for FullScreenWindowDetector on MS Windows can include a window with empty title or invisible ones.
Bug: webrtc:11462
Change-Id: Id09537579ef6617dee29759c66dc9f7493166ca8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171723
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Wez <wez@google.com>
Cr-Commit-Position: refs/heads/master@{#32561}
This change avoids inadvertent capture of certain system windows (e.g.
the Start menu, other taskbar menus, and notification toasts) when
capturing a specific window on Windows.
It stops using EnumWindows for detection of overlapping windows, because
this API excludes these system windows from its enumeration. Using
FindWindowEx instead enumerates these windows.
The enumeration logic is refactored somewhat because a callback is no
longer necessary.
Bug: webrtc:10835
Change-Id: I1cccd44d6ef07f13a68e8daf2d2573d422001201
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161153
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#30022}
* Introduce a FullScreenWindowDetector to manage routines for updating the list of sources being application agnostic, inspired by FullScreenChromeWindowDetector.
* Introduce a FullScreenApplicationHandler to make a decision about changing window to share in application specific way, inspired by FullScreenChromeWindowDetector.
* Remove FullScreenChromeWindowDetector as redundant.
* Add FullScreenApplicationHandler for MS PowerPoint and Apple Keynote on MacOS.
* Add FullScreenApplicationHandler for MS PowerPoint on Windows.
Bug: webrtc:3852
Change-Id: I06507d929308e85b882b2f8210a025afef7f26a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156020
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Justin Uberti <juberti@webrtc.org>
Reviewed-by: Wez <wez@google.com>
Cr-Commit-Position: refs/heads/master@{#29993}
This change adds logic to WindowCapturerWin to capture overlapping
owned/pop-up windows (e.g. menus, dialogs, tooltips). This makes window
capture behavior more consistent regardless of whether
CroppingWindowCapturerWin is used & its conditions for using crop-from-
screen capture are met (in ShouldUseScreenCapturer). (I.e. regardless
of OS version, window shape / translucency, occlusion by another
potentially top-most window, or whether the capturing app has opted in
to using the cropping capturer).
Owned/pop-up windows associated with the selected window are enumerated
then captured individually, with their contents composited into the
final frame.
This change also:
- Crops out the top window border (which exposed a bit of the background
when using the cropping capturer, and resulted in an inconsistent
appearance compared to the side & bottom borders being cropped out).
Bug: chromium:980864
Change-Id: I81c504848a0c0e6bf122aeff437b400e44944718
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148302
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28922}
This change reduces cases where capturing a window with the cropping
capturer captures unrelated windows from the same process. For instance:
- Capturing an Explorer window could include portions of taskbar UI,
e.g. when an auto-hide taskbar or window preview thumbnails are shown
overtop.
- Capturing a window from a process with multiple windows could include
menus/tooltips from another window.
Instead of capturing any window with an empty/matching title created by
the same process, the cropping capturer will capture any window created
by the same thread. While not foolproof, this heuristic seems to capture
menus/tooltips from the window of interest while excluding those from
other top-level windows in practice (assuming those were created by a
separate thread / independent message pump).
Bug: webrtc:10856
Change-Id: I2072c79da9e0158475b442a43b5b96d6ad307bc2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148641
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28824}
This change includes windows owned by the primary captured window in the
captured frames if these conditions are met:
1) The owned window (e.g. dialog) overlaps the primary window (in whole
or part)
2) The primary window is otherwise eligible for the crop-from-screen
path (CroppingWindowCapturer is being used, and other conditions in
ShouldUseScreenCapturer are met)
In practice, this means that dialog windows / message boxes are captured
in many cases where they aren't today. This seems beneficial to some
scenarios (e.g. demonstrating / recording how to do something, or
requesting help with something, that involves dialogs).
This is a logical revert of a change for https://crbug.com/webrtc/8062 .
There's some commentary in the newer bug that attempts to make a case
for revisiting that change. (In summary: cases where a dialog would be
substantialy clipped / partial seem relatively uncommon and have
workarounds. Clipping may already occur for menus & tooltips. Clipping
seems less surprising than complete absence.)
Changing the GA_ROOT flag back to GA_ROOTOWNER is sufficient to restore
the older behavior. The removal of the EnumChildWindows call is just a
minor optimization (it was unnecessary/superfluous, since every child
window would match the GA_ROOT check; dialogs are owned root windows,
not child windows).
Removing condition (2) above (capturing dialogs & other related
overlapping windows when not using the crop-from-screen path) is tracked
by https://crbug.com/980864 .
Bug: webrtc:10767
Change-Id: If7b418365685a7b96dc93901ef9367844f9ee99e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147421
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28711}
This change makes CroppingWindowCapturer::CreateCapturer respect the
detect_updated_region flag if set in the options it's passed on Windows.
Frames captured by the created capturer will now make changes available
via DesktopFrame.updated_region().
Bug: webrtc:10833
Change-Id: Ib973bc58745ebf6e216a7b31f82abec3c6dc9556
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147002
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28694}
As a library, WebRTC should not assume UNICODE and _UNICODE to be
defined globally.
This CL explicitly selects wide character functions and types in
order to build WebRTC with /UUNICODE and /U_UNICODE.
Bug: None
Change-Id: Ie4e2bcb4c5c34aee6f68dc7b5b54b76f088ee3e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128904
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Noah Richards <noahric@chromium.org>
Cr-Commit-Position: refs/heads/master@{#27313}
On Windows 10, the hidden taskbar won't be totally hidden, but having a
2 pixel margin on the screen. While a maximized app window will use up
the full screen, there will be overlapping between a hidden taskbar and
a maximized app window, which will impact window capture to that
maximized window. If the target window doesn't support GDI methods well,
the capture may be black (i.e. Chrome) or still (i.e. Word).
Because there is no solid way to identify a hidden taskbar window, we
have to make an exemption to the overlapping to a maximized window is
2-pixel X screen-width/height, which is thin enough to be noticed in
the cropping result.
Bug: chromium:838062
Change-Id: I9e0fbdf43b4445ca9fbbf5ed43bb266ae726a5b8
Reviewed-on: https://webrtc-review.googlesource.com/c/123261
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#26755}
On Windows, some app windows (i.e. Window Media Player) seems
consisting of several sibling windows, with same window title as the
main window and from same process. Currently CroppingWindowCapturerWin
will think the selected window is overlapped by those windows and
switch to GDI capture method, which is not well supported by many Apps
on Win10 and will fail the window capture.
This cl is to extend the current null title check to include the case
that window has same title as the selected window.
Bug: chromium:865193
Change-Id: Id16b21596ab3b870197758679e5406138ac1a432
Reviewed-on: https://webrtc-review.googlesource.com/89501
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#24046}
Running clang-format with chromium's style guide.
The goal is n-fold:
* providing consistency and readability (that's what code guidelines are for)
* preventing noise with presubmit checks and git cl format
* building on the previous point: making it easier to automatically fix format issues
* you name it
Please consider using git-hyper-blame to ignore this commit.
Bug: webrtc:9340
Change-Id: I694567c4cdf8cee2860958cfe82bfaf25848bb87
Reviewed-on: https://webrtc-review.googlesource.com/81185
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23660}
Chrome uses Windows native framework to show the notification of the
ongoing presenting. This notification window is enumerated as a
separated window which is on top most. If this window blocks the target
window, Chrome can't do the cropping and has to switch to GDI methods.
If GDI methods can't capture the target window, then capturing will fail
until the notification is dismissed.
It's hard to identify the notification window in EnumWindows() callback.
So far it works if we ignore window with no title and class name
prefixed with "Chrome_WidgetWin_" and with certain extended styles,
as so does in this CL.
Bug: chromium:847664
Change-Id: Iafabcb1f685adb91bf092475642151e1475cdf61
Reviewed-on: https://webrtc-review.googlesource.com/79742
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23474}
While investigating some screen-capture-track-end-in-meeting issues, the
relevant rtc error logs are not uploaded to server as other webrtc
modules do, which cause great hardness to identify the reason.
This cl is to use existing trace event methods to store error logs of
desktop capturers.
Bug: chromium:831756
Change-Id: Id0c1b439f9b63916fb9417cf4e6f2b8f3c556fcd
Reviewed-on: https://webrtc-review.googlesource.com/69783
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22866}
Since Windows 10, Windows starts to support virtual desktops. The
problem is when one virtual desktop is not the current one, we can still
enumerate the windows on it, which are still marked as visible by OS.
This causes troubles to decide if a window is on top to be cropped out.
This cl is to utilize a COM API, IsWindowOnCurrentVirtualDesktop of
VirtualDesktopManager, to make sure only the windows on current desktop
will be enumerated.
Bug: chromium:796112
Change-Id: I6e0546e90fbdb37365a8d98694ded0e30791628e
Reviewed-on: https://webrtc-review.googlesource.com/65882
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22842}
In order to eliminate the WebRTC Subtree mirror in Chromium,
WebRTC is moving the content of the src/webrtc directory up
to the src/ directory.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iac59c5b51b950f174119565bac87955a7994bc38
Reviewed-on: https://webrtc-review.googlesource.com/1560
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19845}
