1521955 - ContentSink should interrupt DOM creation if there is pending vsync

Status: NEW

(Core :: DOM: Core & HTML, defect, P2)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: contentsink_interrupt.diff

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2e565697fa2bd102cabd248231cf9113edd1bd9b

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=506c2bb1d81a90f91bff4e52a3338f8d6269924d

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Attachment: contentsink_interrupt_2.diff

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0b50888280141fe24d4b79443e043947630543cd

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Attachment: contentsink_interrupt_3.diff

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 9039526 [details] [diff] [review]
contentsink_interrupt_3.diff

This is not too beautiful. I think we should simplify when to interrupt contentsink, but this is a minimal patch to
evaluate this approach.

Comment 5

[Henri Sivonen (:hsivonen)]

Comment on attachment 9039526 [details] [diff] [review]
contentsink_interrupt_3.diff

Review of attachment 9039526 [details] [diff] [review]:
-----------------------------------------------------------------

I'm a bit worried about doing all the pointer chasing that HighPriorityEventPendingForTopLevelDocumentBeforeContentfulPaint() does on each tree op, but I trust that you've measured that it's better with this patch than without.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I have profiled, and it basically doesn't show up at all. And this case is dealing with after-processing-script-element, which is always slow anyhow.

Comment 7

[Henri Sivonen (:hsivonen)]

(In reply to Olli Pettay [:smaug] (massive needinfo queue, ping on IRC on anything urgent) from comment #6)

And this case is dealing with after-processing-script-element, which is always slow anyhow.

Oh, right. My worry about "each tree op" is indeed wrong. Thanks.