W3C home > Mailing lists > Public > public-houdini@w3.org > August 2015

Re: Isolated Script API

From: Chris Lilley <chris@w3.org>
Date: Fri, 14 Aug 2015 14:31:22 +0200
Message-ID: <164190118.20150814143122@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:24 UTC