Re: New name for "AudioWorker"

I have a strong desire that we spec this with synchronicity in the audio
thread; that is, the nodes all run in the same thread, and would have to
(and should be able to) fork other threads if necessary for processing
purposes.

On Wed, Oct 7, 2015 at 10:24 AM, Paul Adenot <padenot@mozilla.com> wrote:

> Also I was writing a separate draft to spec this, but I'll hold off for
> now.
>
> Paul.
>
> On Wed, Oct 7, 2015 at 7:20 PM, Paul Adenot <padenot@mozilla.com> wrote:
>
>> On Wed, Oct 7, 2015 at 7:12 PM, Ian Kilpatrick <ikilpatrick@chromium.org>
>> wrote:
>>
>>> Hi all,
>>>
>>> Houdini is attempting to add extension points into the rendering
>>> pipeline of browsers. Because of this we need properties similar to what is
>>> required for AudioWorker (at the moment we've called it IsolatedWorker,
>>> fine with changing the name to IsolatedProcessor or something
>>> <bikeshed-here>).
>>>
>>> I'm currently writing a draft of the spec at the moment and should
>>> appear here (https://drafts.css-houdini.org/isolated-workers/) at the
>>> end of the week.
>>>
>>> It will be based on the strawperson discussed at Houdini Paris F2F. (
>>> http://bfgeek.com/css-houdini-drafts/css-script-api/Overview.html).
>>>
>>> A few properties that we'd like from this spec:
>>>  - Thread-agnostic - that is, it does not define on which thread this is
>>> run, may share a thread with something else, i.e. main document context.
>>>  - Subset of APIs - remove network request APIs etc.
>>>
>>
>> I'd rather have this opt-in (you pick the APIs you want) than opt-out
>> (you remove some APIs).
>>
>>
>> The rest is what we need indeed.
>>
>> Paul.
>>
>>
>>>  - Hook based - APIs will be reached by registering callbacks on
>>> GlobalScope, e.g. registerPaint() not event based.
>>>  - Life-cycle - can be created/destroyed at defined points in time.
>>> Similar to ServiceWorker.
>>>
>>
>>> Additionally we've observed that javascript implementations have a high
>>> memory overhead per javascript context. We believe we want to limit the
>>> number created, so similar to the main javascript execution context, code
>>> shares a single javascript execution context. Details of this is probably
>>> better discussed one there is a proposal.
>>>
>>> Ian
>>>
>>> On Wed, Oct 7, 2015 at 9:32 AM, Chris Wilson <cwilso@google.com> wrote:
>>>
>>>> I'm actually off-the-cuff against trying to boil the ocean of the
>>>> general pattern.  This is pretty specific - the new thing , runs *IN*
>>>> something that can be a Worker-like process, but they're expected to share
>>>> the process.  The thing you can instantiate lots of (runtime contexts?) run
>>>> inside that process.
>>>>
>>>> I was expecting we would rename AW to CustomAudioProcessor, still
>>>> define them as running inside a Worker (and define how that Worker-sharing
>>>> works), and use Worker messaging.  That seemed like the shortest path to
>>>> success.
>>>>
>>>> On Wed, Oct 7, 2015 at 9:16 AM, Hongchan Choi <hongchan@google.com>
>>>> wrote:
>>>>
>>>>> Nothing forces workers to be heavy weight, but doesn't it have the
>>>>> assumption that it runs on its own thread? What we want is to be able to
>>>>> throw JS code into VM that runs on the audio thread.
>>>>>
>>>>> Perhaps we can break that assumption, and propose a new type of Worker.
>>>>>
>>>>> On Wed, Oct 7, 2015 at 9:09 AM Alex Russell <slightlyoff@google.com>
>>>>> wrote:
>>>>>
>>>>>> Why isn't this thing a worker? What forces workers to be heavyweight?
>>>>>>
>>>>>> Also, would be good to align with the Houdini folks on this as
>>>>>> they're proposing similar things in the rendering and compositing space.
>>>>>>
>>>>>> Regards
>>>>>> On 7 Oct 2015 7:52 a.m., "Paul Adenot" <padenot@mozilla.com> wrote:
>>>>>>
>>>>>>> We need to decide for a new name for something that:
>>>>>>>
>>>>>>> - Runs off-main-thread
>>>>>>> - Has access to a very limited set of APIs
>>>>>>> - Can be instantiated a lot of times in the same document (much more
>>>>>>> than Workers can or would)
>>>>>>> - Is specialized to one domain (audio, video, etc.)
>>>>>>> - ... ?
>>>>>>>
>>>>>>> It is likely that we would be the first group to spec something like
>>>>>>> this, but it would be used by other groups (layout people, video/image
>>>>>>> processing folks, etc.). We need something that is not too tied to audio,
>>>>>>> or can be adapted. I propose "Processor", which conveys the meaning of
>>>>>>> taking something as input, applying a transformation, and outputting it.
>>>>>>> I'm very open to suggestions though, this is merely to get the ball rolling.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>> Paul.
>>>>>>>
>>>>>>
>>>>
>>>
>>
>