Re: Audio Workers - please review

On Sep 11, 2014, at 2:06 PM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:

> On Thu, Sep 11, 2014 at 9:01 PM, Joseph Berkovitz <joe@noteflight.com> wrote:
> Jussi,
> 
> I agree the issue of importScripts overhead could be pretty major, if this overhead is in fact likely to be substantial. I am not knowledgeable about the extent to which browsers optimize imports of the same scripts in multiple workers. However it is almost a certainty that nodes will want to exploit substantial libraries.
> 
> I did not see a convenient way in your proposed API to make it easy for different nodes based on the same worker to partition their ongoing computational state (maintained in between onaudioprocess callbacks) from each other, though. Did I miss something? Doesn’t there need to be a persistent per-node object that can hold this state?
> 
> The state can for example be provided by a closure in the onaudionodecreated event handler, or using a global WeakMap that uses the AudioNodeHandles as keys. This makes sure that the state associated to the node is garbage collected when the node is.

I see.  Either of the above would work, but it feels like in this model the developer needs to do some more careful bookkeeping about state rather than just sticking state into the node’s dedicated global scope. That makes the approach feel more complex for developers to consume, relative to Chris’s proposal or the original ScriptProcessorNode.

…Joe