Henri Sivonen wrote:
Having all that stuff run in a single thread seems scary, but my view of threading is heavily influenced by Java.
Suggest a better solution... ;)
I suspect it was done to avoid the performance issues involved with dribbling the DOM across thread boundaries bit by bit....
Considering how often the beach ball of death shows up with Firefox, I'm inclined to think that having more thread synchronizations and context switches might be a lesser evil.
Patches accepted (for performance and uset-impact testing, in this case).
Ah, gotta love XSLT. Luckily the style sheet PI is seen before the root element start tag and it does not make sense to ask for a reflow before that.
Right.
>> and that in the other cases you have to carefully keep track of what >> parts of the DOM have already been passed off to
>> the rest of the application
Why? Do the other parts of the app keep private copies? Which other parts? How is the situation with the content sink appending stuff to the DOM different from a script appending stuff except that with the content sink the reflow needs to be explicit?
The main other part we are interested in is the rendering model. When the content sink appends content the DOM it notifies the rendering model constructor of the new content. This causes construction of the relevant rendering objects.
Now rendering model construction is most efficient when it gets the entire document at once and least efficient when it gets the document one node at a time. So the content sink adds content to the DOM as it goes, but doesn't notify the rest of gecko about the new content immediately. After it has buffered up some content this way it notifies for all of it, and the corresponding rendering objects are constructed. See the nsIDocumentObserver interface for the relevant notifications.
So during parsing there may be content that is in the DOM but that the rest of gecko doesn't realize is there yet.
When a script appens content, there is an immediate notification dispatched, instead of batching up notifications like the sink does. See the aNotify arguments to SetAttr/SetParent/SetDocument/AppendChildTo/etc. Those are passed as false by the content sink and as true by JS code and other W3C DOM access.
Apart from all this, there are parts that do sort of keep "private copies" of the DOM or some subset thereof -- content lists are a good example... Those update themselves based on the nsIDocumentObserver notifications.
-Boris _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
