Re: Opening discussion on StreamWorker

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

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.

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

Received on Friday, 18 November 2011 03:31:18 UTC