- From: <bugzilla@jessica.w3.org>
- Date: Thu, 02 Oct 2014 19:25:18 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26957 Bug ID: 26957 Summary: Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Web Workers (editor: Ian Hickson) Assignee: ian@hixie.ch Reporter: brunoaiss@gmail.com QA Contact: public-webapps-bugzilla@w3.org CC: mike@w3.org, public-webapps@w3.org I'd like to revive this bug and ask for a minor alternative that might be possible and OK to go for. The idea is to allow passing document fragments to worker threads (document fragments only). The main idea is that, sometimes, a large amount of changes or analysis are required to be made to the DOM. By allowing sending a fragment to a worker thread, the overhead required to translate all the DOM send into an analyzable format. You may even require http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode Or some work adapting the content to the worker. As long as that is made in the other thread, there's no issue on my end. The main use case here is: Extensive work is required to be made on a subtree of a page's DOM. Here's an example generic use-case. 1. The main thread splits the DOM tree into parts and then it sends those parts to the worker threads. 2. The worker threads do the DOM changes. 3. The worker threads send the changed DOM to the original thread. 4. The original thread integrates the changed DOM nodes from the workers into it's own DOM. The requirements for my use-case are: --- Worker having a nearly complete document DOM --- This document is not connected to any interface. In other words, it acts the same way as a documentFragment towards everything (actually, it can even be an actual documentFragment, if possible). Any changes to it only changes that DOM tree inside the worker thread. --- You can pass DOM objects --- A passed DOM object is read-only on the destination until http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode (or equivalent) is called. This one may be harder to do because there's no synchronization and implementing a copy-on-write may just be too much. OR Passing a DOM is made by cloning it to the document that resides in the worker thread. The result of that clone is equivalent of passing it through the importNode() method. This one should be the easiest to implement. It may be slower, but then it should only affect performance for the first send (considering that there are multiple workers). There can be optimizations here such as for documentFragment. If transfering a documentFragment it could behave just like a Transferable such as ArrayBuffer (once transfered, it cannot be accessed from the source thread). As far as I know, there's no way for a change in a documentFragment to be reflected in the interface's document and vice-versa but there can be internal code requirements that make this optimization impossible. If this is enabled, when the parsing work on the js side is more complicated, it may be sent to the worker thread to deal with the specifics and still have tree-like operations with Nodes that look like the interface's DOM. Just to keep it clear: -> This is still not memory sharing, just memory transfer or memory ownership transfer. -> All changes inside the worker do not reflect on any other thread. I.E. changes on a specific thread's DOM documents do not reflect on any other thread's DOM documents. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 2 October 2014 19:25:20 UTC