[whatwg] [WebWorkers] Advocation to provide the DOM API to the workers

On Fri, Nov 13, 2009 at 1:46 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/12/09 9:21 PM, David Bruant wrote:
>
>> I was waiting for Firefox to stop freezing on the HTML5 spec page (it
>> freezes about one minute each time I visit the one-page version) and I
>> tried to think of a way to "design" this page in a way that wouldn't
>> freeze my browser.
>>
>
> Two easy ways to do this:
>
> 1)  Take out the script at the end of the page that goes and messes
>    with the DOM.
> 2)  Fix the O(N^2) algorithm in the web browser that this script
>    happens to trigger
>    (<https://bugzilla.mozilla.org/show_bug.cgi?id=526394>; should be
>    checked in pretty soon unless something goes drastically wrong).
>
>
>  One good way I have found would be to cut the whole page into several
>> parts (one the server side, what is already done in the multi-page
>> version) and to launch several workers. Each worker gets one part of the
>> whole page in the background and could give it to the browsing context
>> which will append the right part at the right place.
>>
>
> I'm not sure what you mean, exactly... what would the worker "give",
> exactly?
>
>
>  But what is this "give" ? Without the DOM API, this "give" means
>> "sending a string through the postMessage() method" and the "append"
>> means "rightPlace.innerHTML = stringContainingAPartOfThePage".
>> However, with the DOM API, each worker could build independantly its
>> documentFragment, send it to the browsing context which will "append"
>> (appendChild) it in the right place.
>>
>
> The problem here is that of a script making certain DOM mutations after the
> DOM is completely built and reflecting those mutations into the rendering
> tree, not of initial DOM construction.
>
> That is, even if this proposal were implemented it would not eliminate the
> hang you're seeing without item 2 above being addressed.
>
>
>  Building the page requires 3 main operations :
>> - getting the content (can be parallelized with the workers which can
>> make XMLHttpRequests)
>> - building a DOM tree from the content
>> - rendering (cannot be parallelized because must occur in the browsing
>> context)
>>
>
> And in this case the slowness you seem to be trying to address is in the
> "rendering" part.
>
> -Boris
>


The reason WebWorkers don't have access to the DOM is concurrency. For
example, to loop through a list of children I need to first read the number
of childrens, then have a for loop which starts at 0 and ends at length-1.
If you have two threads that can access the DOM concurrently, then one could
change the number of children while the other was looping through the list,
which would cause bugs in the program. The only way to fix this is to make
the DOM a monitor or introduce semaphores, but then you would have to change
the way the DOM is accessed in HTML5, breaking backwards compatibility,
which is not a good idea.

A better solution to your problem is to load fragments of the entire
document using AJAX and then insert those fragments into the main document,
when they are needed. You rarely need to see the entire document at once
anyways.

Marius Gundersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091113/69306a4e/attachment-0001.htm>

Received on Thursday, 12 November 2009 19:43:42 UTC