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
