Since the device_scale_factor is usually exposed as a float in chromium,
we want to keep it same here for consistency.
Bug: chromium:383946052
Change-Id: I8d055ca0fcac623f59dcf96eb3cee15efc23b2ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376700
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43869}
This is a reland of commit e20fbb00d0e0219b710da24664e81a10b12c703a
which failed due to CHECK failing on monitor_id in
DxgiDuplicatorController::GetDeviceScaleFactor(). This has now been
fixed in this CL by removing the check for greater than 0 and instead
returning std::nullopt.
Original change's description:
> Get DeviceScaleFactor for the captured monitor/screen
>
> Accesses DeviceScaleFactor using the windows API
> GetScaleFactorForMonitor and adds it to the DesktopFrame. In a follow-up
> CL, this value is propagated to
> DesktopCaptureDevice::Core::OnCaptureResult where it is added to the
> frame metadata.
>
> In a follow-up CL, add RegisterScaleChangeEvent to get notified whenever
> the device scale factor changes.
>
> Design doc: go/expose-captured-surface-resolution
>
> Bug: chromium:383946052
> Change-Id: I363af33c569419d95ddf31a0cc2f9cecf6fb0c7b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374344
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Palak Agarwal <agpalak@google.com>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43827}
Bug: chromium:383946052
Change-Id: Iffcc889b9a560695302f71623e3e929ecb2489fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376061
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43832}
This reverts commit e20fbb00d0e0219b710da24664e81a10b12c703a.
Reason for revert: Breaks WebRTC roll to Chromium, see:
https://chromium-review.googlesource.com/c/chromium/src/+/6218060
Example of error: https://ci.chromium.org/ui/p/chrome/builders/ci/win-arm64-rel-ready/51821/test-results?sortby=&groupby=
Original change's description:
> Get DeviceScaleFactor for the captured monitor/screen
>
> Accesses DeviceScaleFactor using the windows API
> GetScaleFactorForMonitor and adds it to the DesktopFrame. In a follow-up
> CL, this value is propagated to
> DesktopCaptureDevice::Core::OnCaptureResult where it is added to the
> frame metadata.
>
> In a follow-up CL, add RegisterScaleChangeEvent to get notified whenever
> the device scale factor changes.
>
> Design doc: go/expose-captured-surface-resolution
>
> Bug: chromium:383946052
> Change-Id: I363af33c569419d95ddf31a0cc2f9cecf6fb0c7b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374344
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Palak Agarwal <agpalak@google.com>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43827}
Bug: chromium:383946052
Change-Id: I3065b278939ca0e686ee6da0f0721082bc0c99e8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375902
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43829}
Accesses DeviceScaleFactor using the windows API
GetScaleFactorForMonitor and adds it to the DesktopFrame. In a follow-up
CL, this value is propagated to
DesktopCaptureDevice::Core::OnCaptureResult where it is added to the
frame metadata.
In a follow-up CL, add RegisterScaleChangeEvent to get notified whenever
the device scale factor changes.
Design doc: go/expose-captured-surface-resolution
Bug: chromium:383946052
Change-Id: I363af33c569419d95ddf31a0cc2f9cecf6fb0c7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374344
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43827}
When capturing only one display, it is unnecessary to use
DoDuplicateAll, which allocates bitmap image memory for a rectangle
encompassing all screens and captures all displays. In this case, I
switch to DoDuplicateOne.
I have added an int parameter to GetNumFrameCaptured and
EnsureFrameCaptured to distinguish which display's skip behavior is
currently being executed.
After the modification, when capturing a single monitor in a
multi-monitor environment, only the bitmap image memory of the size of
the captured monitor will be allocated, rather than for all monitors.
Bug: webrtc:391914255
Change-Id: Iee56796c50282beaf1dbeef47f5937fe7fe94a05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375181
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#43822}
I am updating Chrome Remote Desktop to apply a scale factor when using
curtain mode (i.e. a loopback RDP session) and I've found that while
the changes are applied and the desktop is scaled, DXGI stops
producing frames.
This is essentially the same issue as crbug.com/1307357 except this
issue is occurring when the DPI is changed rather than the desktop
size.
The fix is to look at the effective DPI for the source being
captured (or the primary monitor when capturing the full desktop)
and then signaling an environment change when the DPI differs.
Bug: webrtc:14894,b:154733991
Change-Id: Id768d4a384434ba59e7396bc919d0ba30d0f6acc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292791
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#39305}
This records high level errors, or success, encountered across the entire capture flow in the DXGI based capturer.
Using the same style as for WebRTC.DesktopCapture.Win.WgcCapturerResult
Bug: chromium:1400204
Change-Id: I7096d1790d7c2a23bbe29761b7dbf40426ce1e6a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291707
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39259}
DxgiOutputDuplicator objects hold a reference to the last frame that
they succesfully captured by maintaining a reference to the
SharedDesktopFrame that was passed as their target. This is done because
the DirectX capture APIs may fail to provide an update if there has been
no (or no substantial) change since the last capture call was made.
However, the higher levels of this capture stack
(DxgiDuplicatorController and ScreenCapturerWinDirectX), were unaware of
this, and assumed that the caller of CaptureFrame is the only one who
may have held a reference to the frame. Thus, when CaptureFrame is
called, the DirectX screen capturer assumes that the oldest frame in its
queue can be safely reused.
In the steady state, where capture is not being switched between
monitors, this is fine as there are no competing DxgiOutputDuplicators
being run and this assumption mostly holds true (or the frame is being
overwritten only when the DxgiOutputDuplicator is also done holding it).
However, when capture is being rapidly switched between multiple targets
(e.g. to show a preview of each of the available monitors), this can
result in a frame being held by one DxgiOutputDuplicator being passed to
another as a valid target and overwritten. In the common case of only a
single monitor this is essentially the same as steady state capture,
where there are no competing DxgiOutputDuplicator. In the other common
case of two monitors being captured, the fact that the
ScreenCaptureFrameQueue has two frames ends up masking this issue. Since
each monitor is captured in the same order, the same frame ends up
getting passed to each DxgiOutputDuplicator, so no data actually ends
up getting overwritten. In the case of 3 monitors, the 1st and 3rd
monitor end up sharing a frame, which when capture fails on one of them
surfaces as the other monitor being duplicately shown.
This change addresses the issue by ensuring that each screen that the
ScreenCapturerWinDirectX *actually attempts* to capture, gets it's own
FrameQueue, and thus essentially brings us back to the "steady state"
case for each monitor. Note that this does increase memory usage of
capturers that are switched between multiple targets by 2 frames/target
used (and actually attempted to be captured).
Alternatives considered:
DxgiOutputDuplicator makes a copy of the frame, rather than holding
a reference
This was rejected because adding an additional copy for every
capture upon getting a new frame, would expensive and could degrade
performance.
Allow the DxgiOutputDuplicators to "fail" when there has been no update
This would result in either a breaking change to the API for consumers
or would require the ScreenCapturerWinDirectX to track these last
captured frames; which would result in essentially the same approach,
but with less abstraction for re-using the frames.
Bug: chromium:1296228
Change-Id: I5442ec40e9f234046010b562b258db63693ccc6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256043
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36295}
This class is accessed by Electron for its desktop capture support,
but it breaks with component builds on Windows because the symbols
aren't exported by the dll.
No behavior change at runtime, only modifies the generated .lib
when building as a shared library (static builds are unchanged).
Bug: None
Change-Id: I5dc606846de990c1bf4d375ddbb1c73dfc512762
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230200
Reviewed-by: Joe Downing <joedow@chromium.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34858}
This name change communicates that the recursive critical section
should not be used for new code.
The relevant files are renamed rtc_base/critical_section* ->
rtc_base/deprecated/recursive_critical_section*
Bug: webrtc:11567
Change-Id: I73483a1c5e59c389407a981efbfc2cfe76ccdb43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179483
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31754}
The type rtc::scoped_refptr<T> is now part of api/. Please include it from
api/scoped_refptr.h.
More info: See: https://groups.google.com/forum/#!topic/discuss-webrtc/Mme2MSz4z4o.
Bug: webrtc:9887, webrtc:8205
No-Try: True
Change-Id: Ic6c7c81e226e59f12f7933e472f573ae097b55bf
Reviewed-on: https://webrtc-review.googlesource.com/c/119041
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26414}
This is a trivial change to add more logs in DX capturer components for
debugging purpose.
Bug: chromium:764258
Change-Id: I406127d838a522f0226720434e840c7163b4719d
Reviewed-on: https://webrtc-review.googlesource.com/3541
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19960}
In https://webrtc-review.googlesource.com/c/src/+/1560 we moved WebRTC
from src/webrtc to src/ (in order to preserve an healthy git history).
This CL takes care of fixing header guards, #include paths, etc...
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iea91618212bee0af16aa3f05071eab8f93706578
Reviewed-on: https://webrtc-review.googlesource.com/1561
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19846}
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}
