This is to ensure that the device_scale_factor stored per frame is the
latest one according to the system settings and not an old value.
Bug: chromium:383946052
Change-Id: I11e6342201678451554e6883ded48999fd996743
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377541
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43924}
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}
In all the other functions `monitor_id` is a global id from range [0..total monitor count), but each DxgiAdapterDuplicator always assumes that it gets a local id from range [0..adapter monitor count).
Bug: chromium:395807060
Change-Id: I4bb232ee5d83f09859534f813111446763fe9fc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376840
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43867}
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 CL addresses an issue where the desktop appears to freeze after
resizing the desktop in a curtained CRD session when using the DXGI
capturer. This problem does not reproduce when using the GDI capturer
nor does it reproduce when the Windows session is attached to the local
console.
After digging in, it appears that the DXGI DuplicateOutput API stops
providing updated frame data. No errors are returned but yet no data is
produced. The problem is that when in this condition, there isn't a
good way to discern between this problem and a case where the desktop
is actually static.
The DxgiDuplicatorController already contains logic to attempt to
capture a frame prior to returning success after reinitialization. This
logic works fine in the console case and occasionally works in the
detached session case. What I noticed in my reproductions was that DXGI
would produce a few frames before hanging (usually 1-2 but sometimes 3
or 4). My solution is to check the session state and adjust the number
of frames we attempt to capture (I also simplified the wait logic as
there was a bug in the time calc and it seemed more complicated than it
needed to be).
One option considered would be to introduced a new differ class higher
up in the stack which would run the GDI and DXGI capturers in parallel
(instead of in the fallback configuration as they are today) however
that seemed like overkill for this specific issue.
Bug: chromium:1307357
Change-Id: Idba4bb9b2aa7692040344d480be3f0d09b9ce9e9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256214
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@google.com>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#36286}
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 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}
