Show a highlight around any windows shared over WebRTC, or around the edge of the screen when sharing a screen.
Categories
(Firefox :: Site Permissions, enhancement, P3)
Tracking
()
People
(Reporter: mconley, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs, )
Details
Attachments
(8 files, 1 obsolete file)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
2.34 MB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
For bonus points, ideally, these highlights would not be captured by the WebRTC desktop capture layer. That should be a fun challenge.
Reporter | ||
Comment 1•5 years ago
|
||
Hey dminor,
It looks like there's a ::SetExcludedWindow
capability in some of the WebRTC screen capturing stuff, but it looks to me as if it's only implemented for macOS... looking through the Chromium source code, I don't see them using it at all over there, too.
It's likely that we'll need to implement this highlight using a special transparent OS-window, and if we don't want it to be captured during a screen capture, I presume we'd want to use something like ::SetExcludedWindow.
Hey dminor, suppose I were to try to implement ::SetExcludedWindow for Windows... do you know if there'd be any difficulty in getting that change landed in the third-party webrtc code?
Comment 2•5 years ago
|
||
Hi Mike, In this case, since it's already implemented for one platform, I suspect your chances of getting it landed upstream for a different platform are pretty good. The desktop capture code seems to change pretty slowly, so I expect your patch for Firefox would apply upstream without too many difficulties. I have a webrtc.org account, I can help get it up for review once done, although I might need your help addressing any review comments from upstream.
Reporter | ||
Comment 3•5 years ago
|
||
Reporter | ||
Comment 4•5 years ago
|
||
Depends on D75404
Reporter | ||
Comment 5•5 years ago
|
||
Depends on D75406
Updated•5 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
|
||
Reporter | ||
Comment 7•4 years ago
|
||
Depends on D80688
Reporter | ||
Comment 8•4 years ago
|
||
Depends on D80689
Reporter | ||
Comment 9•4 years ago
|
||
Depends on D75408
Reporter | ||
Comment 10•4 years ago
|
||
So the WIP implementation here is a prototype that uses a transparent DOM window to draw the highlight. This appears to mostly work, however there's a bit of a performance penalty on the graphics side of things - since the widget layer isn't drawing the highlight, we can't take advantage of the OS compositor to cheaply composite it, which means that the highlights add overhead. Not a good thing when sharing over WebRTC (which is already pretty intensive from the OS compositor's standpoint).
After consulting with mstange, I'm going to change tack here a little and try having the widget layer draw the highlights. The general idea is to add properties to the nsIAppWindow
and nsIScreen
interfaces to draw the highlights.
Reporter | ||
Comment 11•4 years ago
|
||
Here's a demo from shorlander on how the highlight should be layered to maximize visibility across a variety of backgrounds: http://stephenhorlander.com/sharing-highlight/sharing-highlight.html
Reporter | ||
Comment 12•4 years ago
|
||
Depends on D80690
Reporter | ||
Comment 13•4 years ago
|
||
Depends on D81576
Updated•4 years ago
|
Comment 14•4 years ago
•
|
||
This seems like a nice feature. Mike, are you still working on this? I'm assuming it's backlog for now.
Comment 16•1 year ago
|
||
On macOS bug 1842237 might be a better way to go (but we're still left with solving this for the other OSes).
Description
•