- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Mar 2024 09:58:08 +0000
- To: public-webrtc-logs@w3.org
> It's asserting that injection and its alternative have different side-effects, and which ones an app prefers might differ based on what surface the end-user chose to switch to/from (e.g. whether both or neither have audio). Thanks, now I understand. **Theoretically** speaking - I agree completely. But do we have a **concrete** example of such an app? Are there any apps that decide whether to use MediaRecorder vs. RTCRtpSender based on whether the user shared a window vs. a screen? I am not aware of such apps, and I'd actually be quite surprised if you could name such an app. All apps I know make the decision - when there even is a decision to be made - before invoking getDisplayMedia(). I think it's important that we solicit actual developer feedback and only introduce complexity that serves genuine needs. > I've seen no proposal for how an app might specify its preferences for the different surfaces a user might pick up-front, but am happy to compare complexity of anything presented. I don't think that's relevant. I believe the previous paragraph of my present comment explains why. > How are they not robust to these changes? Do you have an example that is not experimental? 1. Meet displays a [scrim](https://www.zorraquino.com/en/dictionary/ux/what-are-scrims.html) over the local preview of shared windows/screens, but not over the local preview of shared tabs. 2. I believe the example of the experimental API was compelling and deserves our attention. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/4#issuecomment-1978377755 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 5 March 2024 09:58:10 UTC