Re: [mediacapture-region] What makes CropTarget special to require an asynchronous creation? (#17)

> I do not know how Chrome is implemented by I would guess that there is a privileged process that is doing the compositing, might have access to window server and so on, I am talking about this process. Basically this is the process where lives the getDisplayMedia track source. Isn't there such a thing in Chrome implementation? The browser process maybe?

There's a non-trivial system of interactions between the render processes, browser process and GPU process. It's not clear to me how your proposal maps onto our model; I am very confused by [your proposal]( and its reference to such things as "synchronous IPC".

Equally important, it's not clear to me why we can't go with a general, flexible solution that can be easily accommodated by any reasonable user-agent architecture. I am [still waiting]( for an explanation of how this complexity provides a service to higher constituencies. Barring such compelling motivation, what's the use?

> There are no zombie tokens. If a CropTarget is kicked out of the CropTarget capturer process cache, it will still be in the renderer process and capturer process will get it through an IPC exchange. The size of the CropTarget cache can be tailored at will since it is just an optimization and has no impact on JS surfacing functionality.

So now we have a round-robin of cached CropTargets that can be resolved immediately, but if one is ejected we do render-to-render communication to figure out if it's a legitimate CropTarget or not? And we set up this potential channel for communication ahead of time, just in case? And this channel of communication follows the capturer around, and supposedly we only have one, and supposedly it's stationary? And all of this wonderful complexity is in the service of...?

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 19 May 2022 19:09:46 UTC