- From: Chris Lilley <chris@w3.org>
- Date: Fri, 14 Aug 2015 14:31:22 +0200
- To: Ian Kilpatrick <ikilpatrick@chromium.org>, public-houdini@w3.org
Hello Ian, Tuesday, August 11, 2015, 2:56:12 AM, you wrote: > For the Houdini APIs which extend the rendering pipeline, we believe > that we'll need an isolated execution environment for these APIs to > be exposed in. I believe we will, yes. It seems safer and is probably more performant, even though the main rendering thread should not be blocked which removes the major perf worry. > I've written down some initial thoughts here: > http://bfgeek.com/css-houdini-drafts/css-script-api/Overview.html A good and clear read. I am reminded of similar off-main-thread, worker-based concepts in the WebAudio spec, for the AudioWorker [1]. This also has a limited global scope [2]. The emphasis there is to avoid blocking the audio rendering thread at all cost (to avoid glitching) and to not be on the main thread (which would produce severe artifacts). The in assorted WGs working on various worker-based APIs should communicate so that the global scope for workers which need an isolated and limited execution context looks similar for each case, rather than all being developed independently. I don't know if that is possible, maybe each needs it's own specialized context, but it should at least be explored. [1] http://webaudio.github.io/web-audio-api/#the-audioworker-interface [2] http://webaudio.github.io/web-audio-api/#idl-def-AudioWorkerGlobalScope -- Best regards, Chris Lilley Technical Director, W3C Interaction Domain
Received on Friday, 14 August 2015 12:31:26 UTC