Re: Opening discussion on StreamWorker

On Thu, Nov 17, 2011 at 7:30 PM, Charles Pritchard <chuck@jumis.com> wrote:

> On 11/17/2011 4:52 PM, Charles Pritchard wrote:
>
>> Currently, Web Workers provides a "heavy" scope for multithreaded Web
>> Apps to handle heavy data processing.
>>
>> I'd like to draw on those specs and create a new lightweight scope useful
>> for various data processing tasks typically associated with stream
>> processing and GPUs.
>>
>> CSS/FX is looking at custom filter tags using WebGL. I think we can
>> implement these in Workers as well. The most important constraints are that
>> the data is opaque: no shared storage allowed.
>>
>> There are many examples of using web workers to apply effects to 32bit
>> pixel data. Those could be easily applied to CSS pixel filters just as
>> WebGL shaders are.
>>
>> River Trail and W16 are showing us ways in which tight for loops can take
>> advantage of multiple cores.
>>
>> Let's look at these use cases and consider a new lightweight worker
>> scope. Nothing but the bare bones, designed and expected to be used for a
>> very specific type of task.
>>
>> Existing CanvasPixelArray processing scripts are a great place to start.
>> I suspect we'll be able to handle other cases, such as stream ciphers.
>>
>> I'm still trying to bikeshed a name on this... StreamWorker,
>> OpaqueWorker, SimpleWorker, DataWorker etc.
>>
>>
>> Please join me in the discussion. I think we can make rapid progress here
>> now that Transferable has matured and we have two moderately-parallel JS
>> implementations.
>>
>>
> To be more clear: here is some in-the-wild code that is similar to what
> I'd expect to produce and consume with StreamWorker:
> http://code.google.com/p/**chromabrush/source/browse/**
> frontend/js/filter.blur.js<http://code.google.com/p/chromabrush/source/browse/frontend/js/filter.blur.js>
>
> Pseudo-code:
> onmessage(data) { for(... data) { data[i] *= fancyness; };
> postMessage(data); };
>
> In doing this, could attach to CSS such as:   img { filter:
> custom(url('basicpixelworker.**js')); }.
>
> The worker may only use postMessage once, and it must send back an array
> of the same size.
> There are no other options, no ways to pass a message to other contexts,
> no File or IDB or other APIs.
> The concept here is to be very restrictive. That way, no data is leaked,
> and it behaves more like a WebGL shader (think GPGPU) than our existing web
> worker context.
>
> If it's rigid, we can get very good performance, high parallelism, and
> modularity. We can also get quick implementation from vendors.
> And they can decide when they want to optimize.
>

Can you clarify what optimizations are enabled by these workers? It's not
clear to me that removing APIs makes starting up a worker any more
efficient, and I don't think significant efficiencies are enabled by
restricting workers to only sending/receiving a single message per
execution.


>
> As a completely different use case, such a simple worker could provide
> stream encryption, or perhaps some other kind of basic but heavy number
> crunching. Since it's just a simple in-out routine, it can be highly
> optimized and easily added into API pipelines.
>
> These workers would still be backward compatible. They could still be used
> as normal web workers. But in their more basic state, they can be more
> lightweight, there are no side effects
> and so they are more appropriate for massive parallelism.
>
> -Charles
>
>