- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 May 2022 08:47:41 +0000
- To: public-webrtc-logs@w3.org
I think there is a big difference between APIs that are **designed** for cross-render-process communication, and ones that don't. In this particular message I'd like us to think about **performance**. Namely, how long after calling `cropTo(target2)`, the cropping actually changes to `target2`. * With the current design, calling `cropTo()` is not impacted by how busy the main loop is on the render process hosting the target Element, because `cropTo()` only causes IPC with the browser process. * In contrast, @youennf has suggested a design whereby `CropTarget` would encode (behind the scenes) which render process the Element is in. That means that `cropTo(token)` would validate the token through an IPC to that other render process - which means the IPC could be delayed by the other render process, e.g. if it is executing an especially long task. * This matters, because even async APIs should be fast. When changing to a new crop-target, the application wants the new crop to be applied ASAP. * This is NOT a problem for `produceCropTarget` because it happens long before the other process calls `cropTo()`; possibly even before `getDisplayMedia()` is called. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1128595737 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 17 May 2022 08:47:42 UTC