[whatwg] WebWorkers and images

[David Bruant]

Le 07/01/2011 14:40, Berend-Jan Wever a écrit :
> Thanks guys, that makes sense (unfortunately).
>
> So, would it be possible:
>
> 1) To give WebWorkers access to the DOM API so they can create their own
> elements such as img, canvas, etc...?
As I mentionned, Ian Hickson's response also covers provoding the DOM 
API since DOM implementations (besides the document object) aren't 
thread-safe.
So currently no (as far as I know). A (laborious) workaround of that 
would be to reimplement the API

> 2) To create a way to communicate media data between web workers and pages
> without serialization, so they can pass img, video, and/or audio with high
> throughput?
The postMessage method takes "any" as argument. You can learn more about 
this here :
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages
You can pass "structured clone" as messages 
(http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#structured-clone)
Basically I understand it as : any "hand-made" ECMAScript (JavaScript) 
object should pass through by postMessage in WebWorkers. Thanks to this 
you should have "enough structure" to emulate a partial reduced DOM tree 
if you want to pre-format your data without having to pass a string 
(what I understand when you say "serialization").




> 3) Introduce a set of "shared" objects, which are re-entrancy save versions
> of a very limited sub-set of classes in the DOM API.
Once again, DOM implementation thread-safety problem. I wish the same 
features than you, but web browsers aren't ready yet for this.


I wish to see parallelism to the browser as much as you do, but we are 
going to have to wait for a bit to have it fully useful from the web 
developer point of view.


For the record, I know that there is some work going on to add 
parallelism to ECMAScript (JavaScript) itself (and not some DOM 
expansion as WebWorkers are) :
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency

Hope it helps,

David