When screen is zoomed in/out, OSX only updates the parts of Rects currently
displayed on screen, with relative location to current top-left on screen.
This will cause problems when we copy the dirty regions to the captured
frame. So we invalidate the whole screen to copy all the screen contents.
- With CGI method, the zooming will be ignored and the whole screen contents
will be captured as before.
- With IOSurface method, the zoomed screen contents will be captured.
Since we can't know the zooming level and focusing location, so we have
to copy the whole screen region for each frame during rooming. And this
will impact peformance a bit (with IOSurface capturer about 5-10 fps
down on MBP.)
Bug: chromium:911862
Change-Id: Icf123cde4d686ab7ce28fa731bc8dac6925492c8
Reviewed-on: https://webrtc-review.googlesource.com/c/113101
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25936}
It's currently used only by the VCMJitterBuffer and VCMReceiver
classes. Injection is needed by the VCMReceiverTimingTest test, which
defines a subclass(!) of EventWrapper.
Bug: webrtc:3380
Change-Id: I765be0ceac58e941928319cc426ba49f1cbdc5fa
Reviewed-on: https://webrtc-review.googlesource.com/c/113002
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25893}
With Retina monitor connected, OSX and Win10 work differently. OSX will
use logical pixel to cursor location and physical pixel to cursor image.
And Win10 will always use logical coordinate. So the processing in this
patchset should only be applied to OSX only.
Bug: chromium:909784
Change-Id: I038e7769d101fbc3efe08b4739204d523255b609
Reviewed-on: https://webrtc-review.googlesource.com/c/112523
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25850}
Propose resolution of Issue 10011 : (GCC) build fails desktop_capturer.cc:66:66: error: ‘strncmp’ was not declared in this scope
Bug: webrtc:10011
Change-Id: I4afdfd96f8bbc8e39380a365138ab79e237568e3
Reviewed-on: https://webrtc-review.googlesource.com/c/111885
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25790}
Test disabled on TSAN due to repeated failures. There are data races
in a low-level syncronization primitive (semaphore). Since
syncronization primitives should handle that, I think TSAN may be
configured incorrectly.
The locking scheme is written entirely in the unit test. This means we
are losing some test coverage of *unit tests*.
TBR=jamiewalch@chromium.org
Bug: webrtc:10019
Change-Id: Ieafa00a5a789acf8d0bacf6ad669c6daca7efa17
Reviewed-on: https://webrtc-review.googlesource.com/c/111585
Reviewed-by: Alex Loiko <aleloi@webrtc.org>
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25723}
This reverts commit a13be019017449c57f48203d0fb778f34f7553a7.
Reason for revert: The GN definitions cause problems for downstream tooling. They're also generally complicated and reach deep into Chromium's build which is undesirable. Setting `rtc_use_pipewire = true` by default should also be re-evaluated.
Original change's description:
> Default to dlopening the PipeWire.
>
> Reuse the existing infra from Chromium to do that. Additionally the
> target_gen_dir needs to the added to the include directories, otherwise
> the Chromium build will fail as it won't find the generated stubs. Also the
> pw_properties_new() was replaced with pw_properties_new_string() as it doesn't
> require a variadic parameter because the //tools/generate_stubs/generate_stubs.py
> doesn't work with them correctly. With all these changes in place the PipeWire
> support is enabled when compiling on Linux.
>
> Bug: chromium:682122
> Change-Id: I3bbc5efaecd9a08e20cbcf998b2cb534224eae7d
> Reviewed-on: https://webrtc-review.googlesource.com/c/111081
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Brave Yao <braveyao@webrtc.org>
> Commit-Queue: Tomáš Popela <tomas.popela@gmail.com>
> Cr-Commit-Position: refs/heads/master@{#25720}
TBR=phoglund@webrtc.org,mbonadei@webrtc.org,braveyao@webrtc.org,tomas.popela@gmail.com
Change-Id: Iec20b07cb1cff7d57f8114ac6ec2d0d250e61214
No-Try: true
Bug: chromium:682122
Reviewed-on: https://webrtc-review.googlesource.com/c/111584
Reviewed-by: Oleh Prypin <oprypin@webrtc.org>
Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25722}
Reuse the existing infra from Chromium to do that. Additionally the
target_gen_dir needs to the added to the include directories, otherwise
the Chromium build will fail as it won't find the generated stubs. Also the
pw_properties_new() was replaced with pw_properties_new_string() as it doesn't
require a variadic parameter because the //tools/generate_stubs/generate_stubs.py
doesn't work with them correctly. With all these changes in place the PipeWire
support is enabled when compiling on Linux.
Bug: chromium:682122
Change-Id: I3bbc5efaecd9a08e20cbcf998b2cb534224eae7d
Reviewed-on: https://webrtc-review.googlesource.com/c/111081
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Commit-Queue: Tomáš Popela <tomas.popela@gmail.com>
Cr-Commit-Position: refs/heads/master@{#25720}
The content_unittests failure was caused by wrong path in the cfi
blacklist (when the files from x11 folder were moved to the linux
folder by this change).
Bug: chromium:682122
Change-Id: I4f7f6c5a73a981feeac18494749f85935e812981
Reviewed-on: https://webrtc-review.googlesource.com/c/110461
Commit-Queue: Tomáš Popela <tomas.popela@gmail.com>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25621}
This reverts commit dd20c9c1e3f681f6c33d1879c76f588bd4b095bd.
Reason for revert: Speculative revert; looks like it causes crashes on official builders. See crbug.com/901319.
Original change's description:
> Add support for screen sharing with PipeWire on Wayland
>
> Currently, when users want to use the screen sharing and are using the
> Wayland display server (the default on Fedora distribution), then it
> doesn't work, because the WebRTC only includes the X11 implementation.
> This change adds the support by using the PipeWire multimedia server.
>
> The PipeWire implementation in WebRTC stays in
> screen-capturer-pipewire.c and is guarded by the rtc_use_pipewire build
> flag that is automatically enabled on Linux.
>
> More information are included in the relevant commit messages.
>
> Tested on the current Chromium master and Firefox.
>
> The sysroot changes are requested in:
> https://chromium-review.googlesource.com/c/chromium/src/+/1258174
>
> Co-authored-by: Jan Grulich <grulja@gmail.com>
> Co-authored-by: Eike Rathke <erathke@redhat.com>
> Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
>
> BUG=chromium:682122
>
> Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
> Reviewed-on: https://webrtc-review.googlesource.com/c/103504
> Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
> Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
> Reviewed-by: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#25461}
TBR=phoglund@webrtc.org,jamiewalch@chromium.org,niklas.enbom@webrtc.org,braveyao@webrtc.org,tomas.popela@gmail.com
# Not skipping CQ checks because original CL landed > 1 day ago.
NOPRESUBMIT=true
Bug: chromium:682122, chromium:901319
Change-Id: I4ca5da77daea73cae1232953a0d633900a85a93d
Reviewed-on: https://webrtc-review.googlesource.com/c/109584
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25522}
Currently, when users want to use the screen sharing and are using the
Wayland display server (the default on Fedora distribution), then it
doesn't work, because the WebRTC only includes the X11 implementation.
This change adds the support by using the PipeWire multimedia server.
The PipeWire implementation in WebRTC stays in
screen-capturer-pipewire.c and is guarded by the rtc_use_pipewire build
flag that is automatically enabled on Linux.
More information are included in the relevant commit messages.
Tested on the current Chromium master and Firefox.
The sysroot changes are requested in:
https://chromium-review.googlesource.com/c/chromium/src/+/1258174
Co-authored-by: Jan Grulich <grulja@gmail.com>
Co-authored-by: Eike Rathke <erathke@redhat.com>
Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
BUG=chromium:682122
Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
Reviewed-on: https://webrtc-review.googlesource.com/c/103504
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25461}
This class exposes Wait()-Set() logic to synchronize events.
- There is a bug in checking EventWrapper::Wait() as it returns [1,2]. Negating
these values cause us to always pass timeout checks.
- There is a general problem in this class with waiter. There are 2 scenarios:
1) Lock()-Unlock()-DisplaysReconfigured()
In this scenario, Wait() in DisplaysReconfigured() immediately passes as event
is already signaled. Next Lock() call won't continue until Set() is called in
DisplaysReconfigured(). This blocks capture thread from accessing display until
reconfiguration completes.
2) Lock()-DisplaysReconfigured()-Unlock()
In this scenario, Wait() in DisplaysReconfigured() passes when Unlock() called.
Capture thread accesses display while reconfiguration happens. Note that we are
only delaying the OS delegate thread here. As an experiment, adding Sleep() in
DisplaysReconfigured() results in no change, because it looks like OS uses this
thread for only delegates but not for the actual display switch.
Overall, (1) doesnt seem necessary as (2) already accesses display while
reconfiguration happens. (2) doesn't seem necessary as blocking system delegate
thread doesn't help. Therefore, I changed the class to only protect from race
condition on |desktop_configuration_|.
Bug: chromium:796889
Change-Id: I37263305e5ac629e21ff9e977952cf4a21bae19f
Reviewed-on: https://webrtc-review.googlesource.com/c/108560
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25437}
This CL uses RTC_EXPORT (defined in rtc_base/system/rtc_export.h)
to mark WebRTC symbols as visible from a shared library, this doesn't
mean these symbols are part of the public API (please continue to refer
to [1] for info about what is considered public WebRTC API).
[1] - https://webrtc.googlesource.com/src/+/HEAD/native-api.md
Bug: webrtc:9419
Change-Id: I67a4d016a11deca5ac5459826741dd2d3f7931d5
Reviewed-on: https://webrtc-review.googlesource.com/c/107400
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25298}
This reverts commit 9e24dcff167c4eb3555bf0ce6eaba090c10fbe53.
Reason for revert: Breaks chromium.webrtc.fyi bots.
Original change's description:
> Export symbols needed by the Chromium component build (part 1).
>
> This CL uses RTC_EXPORT (defined in rtc_base/system/rtc_export.h)
> to mark WebRTC symbols as visible from a shared library, this doesn't
> mean these symbols are part of the public API (please continue to refer
> to [1] for info about what is considered public WebRTC API).
>
> [1] - https://webrtc.googlesource.com/src/+/HEAD/native-api.md
>
> Bug: webrtc:9419
> Change-Id: I802abd32874d42d3aa5ecd3c8022e7cf5e043d99
> Reviewed-on: https://webrtc-review.googlesource.com/c/103505
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#24969}
TBR=mbonadei@webrtc.org,kwiberg@webrtc.org,nisse@webrtc.org
Change-Id: I01f6e18f0d2c0f0309cdaa6c943c3927e1f1f49f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9419
Reviewed-on: https://webrtc-review.googlesource.com/c/103720
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24974}
This CL uses RTC_EXPORT (defined in rtc_base/system/rtc_export.h)
to mark WebRTC symbols as visible from a shared library, this doesn't
mean these symbols are part of the public API (please continue to refer
to [1] for info about what is considered public WebRTC API).
[1] - https://webrtc.googlesource.com/src/+/HEAD/native-api.md
Bug: webrtc:9419
Change-Id: I802abd32874d42d3aa5ecd3c8022e7cf5e043d99
Reviewed-on: https://webrtc-review.googlesource.com/c/103505
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24969}
This CL removes some deprecated build targets (and their headers)
from system_wrappers:
- field_trial_api
- field_trial_default
- metrics_api
- metrics_default
It also refreshes all the dependencies on field_trial.h and metrics.h.
A nice side effect is that it is finally possible to remove 'nogncheck'
from the following files (when it was used with field_trial_default
and metrics_default):
- sdk/objc/api/peerconnection/RTCMetricsSampleInfo+Private.h
- sdk/android/src/jni/pc/peerconnectionfactory.cc
- sdk/objc/api/peerconnection/RTCFieldTrials.mm
Bug: webrtc:9631
Change-Id: Ib621f41ef8ad0aba4fe1c1d7e749c044afc956c3
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/100524
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24878}
Fixes issues when using the display arrangement utility. The region
outside of the screens had random data when re-arranging displays
while capturing. This CL makes sure this region is always black.
Bug: webrtc:9703
Change-Id: I1481dd0f1b4584e75926755f9b8a6e5161cd5904
Reviewed-on: https://webrtc-review.googlesource.com/97184
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24589}
Thanks to the CL https://webrtc-review.googlesource.com/c/src/+/83822
there is now no need to destroy the stream asynchronously.
But the CL above introduced a leak, the streams were stopped but
not destroyed. This CL essentially fixes the leak, it is now safe
to destroy the stream right after being stopped as everything happen
in the same capture thread.
Bug: chromium:851883
Change-Id: I4bf7409246f3957d90040d0d8cf09e98f28d6559
Reviewed-on: https://webrtc-review.googlesource.com/96621
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24519}
This CL separates the files under sdk/objc into logical directories, replacing
the previous file layout under Framework/.
A long term goal is to have some system set up to generate the files under
sdk/objc/api (the PeerConnection API wrappers) from the C++ code. In the shorter
term the goal is to abstract out shared concepts from these classes in order to
make them as uniform as possible.
The separation into base/, components/, and helpers/ are to differentiate between
the base layer's common protocols, various utilities and the actual platform
specific components.
The old directory layout that resembled a framework's internal layout is not
necessary, since it is generated by the framework target when building it.
Bug: webrtc:9627
Change-Id: Ib084fd83f050ae980649ca99e841f4fb0580bd8f
Reviewed-on: https://webrtc-review.googlesource.com/94142
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24493}
Move base64.h to the proper location and put redirect header into the
old place to be able to switch downstream users on new location.
Bug: webrtc:8366
Change-Id: I5191fe631d32178d2efd1315ca9abd4250102291
Reviewed-on: https://webrtc-review.googlesource.com/88223
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24069}
This CL removes //build/config/clang:find_bad_constructs from the
suppressed_configs list, which means that clang:find_bad_constructs
is now enabled on these translation units.
Bug: webrtc:9251, webrtc:163
Change-Id: I7ad7b03ae1b28fbf5712e671f361928c5e6d7a18
Reviewed-on: https://webrtc-review.googlesource.com/89384
Reviewed-by: Sergey Ulanov <sergeyu@google.com>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Commit-Queue: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#24047}
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}
This cl is to move the RegisterRefreshAndMoveHandlers to be done on
capture thread, and reverse some execution order of releasing processing,
also remove a lock since the handler is on capturing thread too.
As we doubt the existing sequence may be the cause of a crash due to
race conditions at end of capture.
Bug: chromium:851883
Change-Id: I2254a69815144415424a77b4c82f150cfc369585
Reviewed-on: https://webrtc-review.googlesource.com/83822
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#23647}
Extract rtc_base/base64.h and rtc_base/base64.cc into separate target
to prepare to move them into third_party
Bug: webrtc:8366
Change-Id: I477e6da2b9d09307439b3272261f31042f479d74
Reviewed-on: https://webrtc-review.googlesource.com/83980
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23645}
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}
This is a reland of 89653d5db46419d2a80898635cb27fed64898db2
Original change's description:
> [desktopCapture] Unify the position info in DIP coordinates on Mac.
>
> On OSX, the logical(DIP) and physical coordinates are used mixingly.
> For example, the captured image has its size in physical pixels(2x) and
> location in logical(DIP) pixels. Same to the cursor position. This
> causes trouble when we check the relative position of image and cursor
> when there are multiple monitors with different DIP setting connected.
>
> This cl proposed a solution to use DIP pixel for any location info,
> i.e. top-left of a frame and cursor position. Also propose a method to
> get the current scale factor of a window across multiple monitors. And
> save the current scale factor in DPI of the capture frame.
> Then we can check relative position of cursor and frame correctly
> in DIP pixel and compose them in physical pixel.
>
> Bug: webrtc:9178
> Change-Id: I3c076aeac2d6f2c1f63d000d7fff03500aa375ac
> Reviewed-on: https://webrtc-review.googlesource.com/71621
> Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
> Reviewed-by: Zijie He <zijiehe@chromium.org>
> Commit-Queue: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23263}
Bug: webrtc:9178
Change-Id: I97d9150f7b9a4ed6671733b75613ea9c315d5c1d
Reviewed-on: https://webrtc-review.googlesource.com/77481
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23289}
This reverts commit 89653d5db46419d2a80898635cb27fed64898db2.
Reason for revert:
Tentatively revert since I believe this break remoting unittests on Asan/Tsan
https://chromium-review.googlesource.com/c/chromium/src/+/1063330https://chromium-swarm.appspot.com/task?id=3d8692bedcc85c10&refresh=10&show_raw=1
Original change's description:
> [desktopCapture] Unify the position info in DIP coordinates on Mac.
>
> On OSX, the logical(DIP) and physical coordinates are used mixingly.
> For example, the captured image has its size in physical pixels(2x) and
> location in logical(DIP) pixels. Same to the cursor position. This
> causes trouble when we check the relative position of image and cursor
> when there are multiple monitors with different DIP setting connected.
>
> This cl proposed a solution to use DIP pixel for any location info,
> i.e. top-left of a frame and cursor position. Also propose a method to
> get the current scale factor of a window across multiple monitors. And
> save the current scale factor in DPI of the capture frame.
> Then we can check relative position of cursor and frame correctly
> in DIP pixel and compose them in physical pixel.
>
> Bug: webrtc:9178
> Change-Id: I3c076aeac2d6f2c1f63d000d7fff03500aa375ac
> Reviewed-on: https://webrtc-review.googlesource.com/71621
> Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
> Reviewed-by: Zijie He <zijiehe@chromium.org>
> Commit-Queue: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23263}
TBR=zijiehe@chromium.org,jamiewalch@chromium.org,perkj@webrtc.org,braveyao@webrtc.org
Change-Id: Ica02365925623e21b256d20a21b5625e7ed6f49b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9178
Reviewed-on: https://webrtc-review.googlesource.com/77461
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23280}
On OSX, the logical(DIP) and physical coordinates are used mixingly.
For example, the captured image has its size in physical pixels(2x) and
location in logical(DIP) pixels. Same to the cursor position. This
causes trouble when we check the relative position of image and cursor
when there are multiple monitors with different DIP setting connected.
This cl proposed a solution to use DIP pixel for any location info,
i.e. top-left of a frame and cursor position. Also propose a method to
get the current scale factor of a window across multiple monitors. And
save the current scale factor in DPI of the capture frame.
Then we can check relative position of cursor and frame correctly
in DIP pixel and compose them in physical pixel.
Bug: webrtc:9178
Change-Id: I3c076aeac2d6f2c1f63d000d7fff03500aa375ac
Reviewed-on: https://webrtc-review.googlesource.com/71621
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23263}
Always having the latest iosurface before invalidating a region.
Otherwise if CaptureFrame() happens in between, the capture result
may not be fully refreshed. Also we can't add lock since it will
impact performance.
Bug: webrtc:8652
Change-Id: Ib23105b16065018c691685083b76a771ce8771d3
Reviewed-on: https://webrtc-review.googlesource.com/74643
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23154}
The MBP having both discrete and integrated graphic cards will do
automate graphics switching by default. When it switches from discrete to
integrated one, the current display ID of the built-in display will
change and this will cause screen capture stops.
So make screen capture of built-in display continuing even if its display
ID is changed.
Bug: chromium:836979
Change-Id: If4f2d04d99a2690ccd6f894d94e6f8ff58ba2ec8
Reviewed-on: https://webrtc-review.googlesource.com/72603
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23048}
This removes posix-only files from the default source set, forcing
them to be explictly included for the desired configurations.
Bug: chromium:812974
Change-Id: Ic4a1561f87395801ca4d3936a95a66fd4270c5ef
Reviewed-on: https://webrtc-review.googlesource.com/70564
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#22913}
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}
The issue is visible when reconfiguring the screen arrangement while
sharing the displays. Can sometimes be seen right after starting the
screen sharing.
Indeed CaptureFrame can be called at any time so TakeLatestFrameForDisplay
should always return a valid frame and the call should not empty the
internal container.
Also add missing teardown in the provider on failure case.
Bug: webrtc:8652
Change-Id: Ice151c1da92b9ad2b86ca9368d30d9d21114e53e
Reviewed-on: https://webrtc-review.googlesource.com/69420
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#22846}
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}
The given IOSurfaceRef was ignored until now. Wrap it into the new
DesktopFrameIOSurface. The new DesktopFrameProvider object is there
to manage them as it has to be done per display id.
From initial measurement this speed-up the frame capture by 2.
Disabled by default for now but it can be enabled by calling
options.set_use_iosurface. This CL will allow to do some advanced
tests.
Bug: webrtc:8652
Change-Id: Ia9ac0b69b30098774941cb378804b45cb1710119
Reviewed-on: https://webrtc-review.googlesource.com/33014
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#22801}
|is_posix| will be switched to false for Fuchsia, this is a preliminary change.
Bug: chromium:812974
Change-Id: I3bfda3e056ad1e5229834286ce5d095d9204a428
Reviewed-on: https://webrtc-review.googlesource.com/65782
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#22753}
