- From: Yoav Weiss via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 May 2022 15:07:15 +0000
- To: public-webrtc-logs@w3.org
> Regarding performance claims, it would seem faster to _not_ block postMessage, and let it happen in parallel with Chrome's implementation of produceCropTarget, and have cropTo deal with it not arriving in time with some backup strategy (try again a few times, or worst case do some IPC) before giving up entirely. This would seem the absolute fastest success path if it arrives in time, and worst case no slower than today where you're essentially serializing the two steps of generating the key and postMessaging it. We have four options: browser-side sync, browser-side async, renderer-side sync and renderer-side async. Let's examine the performance characteristics of each, shall we? ## renderer-side token production Renderer side token production would require to establish renderer-to-renderer communications. If these communication channels are established on the main thread, sync failures are possible, but the downside is that a busy main-thread on SLIDE would mean that `cropTo` takes a long time to return. If the communication channels are established in an auxiliary thread, that requires a lock when minting, which means we should go with an async interface, to avoid locking the main thread on this lock. ## Browser-side sync token production A sync API and browser-side minting would not enable developers of SLIDE to know that the minting has failed (e.g. due to excessive minting of tokens on their behalf). The reason for that is that the communication to the browser process is async by nature, so the immediately returned token may or may not be a valid one. In this case, we’d be relying on the VC side to notice failures when using `cropTo` and notify SLIDE’s developers in case it’s their fault. Another issue is that with a sync API, we can have a race condition where `cropTo` is called by VC *before* the IPC from SLIDE has successfully completed. Yet another case is VC calling `cropTo` with an expired token (e.g. the SLIDE document was detached). How would an async `cropTo` with sync token minting respond to each one of those failure cases? The async `cropTo` would need in this case to send an IPC to the browser process. If the token is in the token container, then all is well and `cropTo` is resolved. If it’s not, it could be any one of the above cases: * The token’s IPC hasn’t yet arrived * The token was removed from the container * The token is invalid because of bugs, it’s coming from a compromised renderer or any other reason In order to properly handle the first case, the browser process would have to e.g. add an observer to token minting that would resolve the `cropTo` promise once the token has arrived. But it would also need to have some sort of timeout that rejects `cropTo` after X seconds when the token doesn’t arrive. That means that errors of using a removed or invalid token will take a long time to resolve. While one can argue that we could keep past tokens in memory, it’s unclear for how long that would be required. This would also have the undesired side-effect of increasing the long-lived browser process’ memory footprint (hurting users). ## Browser-side async token production Finally, an async `produceCropTarget` would tell SLIDE when minting failed, and enable for shorter debug cycles. It would also make sure that SLIDE doesn’t send the token to VC before the browser side is ready for it. That eliminates the “token hasn’t yet arrived” case, eliminating the need for timeouts and lengthy failures in case an invalid token is used by VC. -- GitHub Notification of comment by yoavweiss Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1131846988 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 May 2022 15:07:16 UTC