This CL adds a new property to the DesktopFrame interface to indicate
that the capturer supports cursor capture and the frame may contain
an image of the cursor (if the cursor was over the window or screen
being captured). This allows the DesktopAndCursorComposer to avoid
compositing another image of the cursor on the frame.
This is preferred because natively capturing the cursor will likely
be more efficient, and for WGC the API to disable cursor capture
is only availabe on later versions of Win10, reducing the number
of users that could use it.
Bug: webrtc:12654
Change-Id: I992804ff2a65eb423fb8ecc66e066408dc05e849
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215341
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33780}
This reverts commit 61709a3233174618d5ab46e1ee5847e4b150c7ef.
Reason for revert: Some downstream projects have issues building this
change due to the inclusion of the <windows.graphics.capture.h> header
which is newly available in the Win 10 SDK v10.0.19041.
To get around this issue for now, this change adds an off-by-default
build flag for these files. However, in the future we will want to
toggle this flag on, and the downstream projects will either need to
update their SDK versions or toggle this flag in their WebRTC clone.
Original change's description:
> Revert "Begin implementing WGC CaptureFrame"
>
> This reverts commit e820cef5340610b9beebbcb63868743b95b97fcd.
>
> Reason for revert: Breaks downstream client. I will investigate and
> get back with a suggestion to fix.
>
> Original change's description:
> > Begin implementing WGC CaptureFrame
> >
> > This change introduces the design that will allow us to deliver frames
> > synchronously to callers despite the Windows.Graphics.Capture APIs being
> > inherently asynchronous.
> >
> > We achieve this by having WindowCapturerWinWgc create and maintain a
> > WgcCaptureSession object for each window that it is asked to capture a
> > frame for. The capture session object will be the class that actually
> > uses the WGC APIs, and it will store the frames it receives in a frame
> > pool and deliver them via GetMostRecentFrame.
> >
> > The next CL will add the necessary functionality to the
> > WgcCaptureSession class.
> >
> > Bug: webrtc:9273
> > Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
> > Commit-Queue: Austin Orion <auorion@microsoft.com>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#32240}
>
> TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,auorion@microsoft.com
>
> Change-Id: I114944357ce5be7d1e2da817703dc95d544aa99a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:9273
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186045
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32248}
Bug: webrtc:9273
Change-Id: I9644fbf8f1fd1a84cb716176b8f14e3683a3f7cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186423
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32286}
This reverts commit e820cef5340610b9beebbcb63868743b95b97fcd.
Reason for revert: Breaks downstream client. I will investigate and
get back with a suggestion to fix.
Original change's description:
> Begin implementing WGC CaptureFrame
>
> This change introduces the design that will allow us to deliver frames
> synchronously to callers despite the Windows.Graphics.Capture APIs being
> inherently asynchronous.
>
> We achieve this by having WindowCapturerWinWgc create and maintain a
> WgcCaptureSession object for each window that it is asked to capture a
> frame for. The capture session object will be the class that actually
> uses the WGC APIs, and it will store the frames it receives in a frame
> pool and deliver them via GetMostRecentFrame.
>
> The next CL will add the necessary functionality to the
> WgcCaptureSession class.
>
> Bug: webrtc:9273
> Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32240}
TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,auorion@microsoft.com
Change-Id: I114944357ce5be7d1e2da817703dc95d544aa99a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9273
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186045
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32248}
This change introduces the design that will allow us to deliver frames
synchronously to callers despite the Windows.Graphics.Capture APIs being
inherently asynchronous.
We achieve this by having WindowCapturerWinWgc create and maintain a
WgcCaptureSession object for each window that it is asked to capture a
frame for. The capture session object will be the class that actually
uses the WGC APIs, and it will store the frames it receives in a frame
pool and deliver them via GetMostRecentFrame.
The next CL will add the necessary functionality to the
WgcCaptureSession class.
Bug: webrtc:9273
Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32240}
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}
And fill-in icc profile from the various window and screen capturers.
Done on WindowCapturerMac, ScreenCapturerMac, WindowCapturerX11
and ScreenCapturerX11. Follow-up CLs will do it on ScreenCapturerWinDirectx
and ScreenCapturerPipeWire.
Useful to build the gfx::ColorSpace in chromium, especially
from src/content/browser/media/capture/desktop_capture_device.cc.
We do not build the color space directly here to avoid duplicating
ui/gfx/icc_profile.h,cc code from chromium, which one implements
icc profile caching.
Bug: chromium:945468
Change-Id: Id6e3920233771e035f7578847406bf1f519dcd49
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133580
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#27697}
When setting display scale to 200%, the mouse was shared only
for the top left quarter.
Regressed since https://chromium-review.googlesource.com/641075.
Indeed frame->rect() takes into account scale_factor while the
frame is constructed with a size that does not take this scale
factor into account.
Also make sure to do a float disivison in DesktopFrame::scale_factor()
so that it returns 1.5 instead of 1 when dpi is 144 (i.e. 150%).
Bug: chromium:948362
Change-Id: Ic10f44946c9f1b53181244a44a5b45109c259f9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130371
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#27424}
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}
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 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}
Now that we have moved WebRTC from src/webrtc to src/, common_types.h
and typedefs.h are triggering a cpplint error.
The cpplint complaint is:
Include the directory when naming .h files [build/include] [4]
This CL disables the error but we have to remove these two headers
from the root directory.
NOPRESUBMIT=true
Bug: webrtc:5876
Change-Id: I08e1b69aadcc4b28ab83bf25e3819d135d41d333
Reviewed-on: https://webrtc-review.googlesource.com/1577
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@google.com>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19859}
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}
