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

[Boris Zbarsky]

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