Re: ScriptProcessorNode off the main thread (Was: Questioning the current direction of the Web Audio API)

2013-10-25 23:11, Joseph Berkovitz skrev:
>> Another thing is that it doesn't really make sense to create 1 worker per node. You'd be much better off using a single worker for all nodes on a given page, or at most one worker per CPU core the system has.
> I agree, although I also think this remark of ROC's also highlights the fact that "Worker" has slightly different meanings for different people.
> On the one hand, "Worker" represents the abstract idea of "a designated script running in a controlled, isolated runtime environment". I think that is the way many of us are talking about it. On the other hand, it also represents a pre-existing implementation concept that has various known costs and overheads.
> ..Joe

Yes. For instance most implementations consider Workers to be 
independendent threads that can execute concurrently, which I think is 
of little use for the audio node use case (I think most nodes would be 
executed in series anyway). On the ohter hand that's not a requirement 
for Workers AFAICT (in fact, Presto would execute all Workers in a 
single OS thread).

That's not my main concern though. I'm thinking more about each audio 
node having it's own, isolated scripting context, which I think would be 
very useful. The problem then becomes the set-up time & memory overhead 
for each node: how much does a regular Worker cost in terms of set-up & 

Unless we want to depart from the ECMAScript specification, we'd at 
least need a full ECMAScript environment (not sure what cost that implies).


Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software

Received on Monday, 28 October 2013 08:13:15 UTC