- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 May 2021 09:42:57 +0000
- To: public-webrtc-logs@w3.org
> * Applications migrating from canvas that have all their logic on the main thread and seek a gradual migration (we've seen this in among some participants in our origin trial) My guess is that applications complexity mostly lies in the processing of the data, not in how to get the data: WebGL shaders, WASM libraries... I think the requirement is to make sure such processing are feasible and easy to deploy in the environments we are envisioning. > * Any application handling low loads including demos and toys, but also some production applications. Demos should show the preferred way of using the API. Toys are product applications. In general, this is a difficult choice and it highly depends on the application and the device running the application. Say a device with a buffer pool of 3 frames, application doing 10fps and GC triggering random hundred millisecond freezes. As an example, ScriptProcessorNode is probably fine for some applications on some devices. > In fact, it can be a way to shoot yourself in the foot. If you do processing that requires a lot of CPU on a real-time priority thread you run the risk of starving everything else, including UI and other things running on the main thread. Agreed and that is precisely the point: isolate potentially perf sensitive tasks in their own context to let the UA do the prioritisation, potentially dynamically. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/23#issuecomment-843021783 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 May 2021 09:43:13 UTC