Don't use DesktopAndCursorComposer with ScreenCaptureKit
Categories
(Core :: WebRTC: Audio/Video, task)
Tracking
()
People
(Reporter: pehrsons, Assigned: pehrsons)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-esr128+
|
Details | Review |
DesktopAndCursorComposer on macOS is rather expensive, even if it never composes (because the cursor was embedded from the backend). The cost is in comparing the previous and the current cursor to see if it had changed. This is done by converting both cursors to TIFF and comparing all their pixels. On every frame.
ScreenCaptureKit can embed the cursor directly, so use that mode instead, and skip the composer entirely.
Assignee | ||
Comment 1•7 months ago
|
||
The MouseCursorMonitor on macOS is rather expensive, as for every pulled frame
it compares all pixels of the cursors used for the current and last frames.
Getting to the pixels may also incur a conversion.
Note that this comparison happens even if the backend reports it had embedded
the cursor already, as the embedding only affects composing the monitored cursor
into a captured frame.
Assignee | ||
Comment 2•7 months ago
|
||
With the composer: https://share.firefox.dev/4dYhbeJ
Without: https://share.firefox.dev/3MikrFY
Comment 4•6 months ago
|
||
bugherder |
Assignee | ||
Comment 5•3 months ago
|
||
The MouseCursorMonitor on macOS is rather expensive, as for every pulled frame
it compares all pixels of the cursors used for the current and last frames.
Getting to the pixels may also incur a conversion.
Note that this comparison happens even if the backend reports it had embedded
the cursor already, as the embedding only affects composing the monitored cursor
into a captured frame.
Original Revision: https://phabricator.services.mozilla.com/D220092
Updated•3 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Description
•