We can hit many redundant-seeming `nsIFrame::SchedulePaint` calls after painting has been unsuppressed, in resumed initial reflow of a deeply-fragmented tree
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:pageload)
See bug 216418 comment 49 -- this testcase...
https://bugzilla.mozilla.org/attachment.cgi?id=9324995
...still has us spending 30% of our reflow in calls to SchedulePaint (and particularly in its call to InvalidateDirectRenderingObservers).
This is happening after we've unsuppressed painting and done an initial paint of the top of the document, so we're not benefiting from bug 1832684's patch (which is condition on painting being suppressed). Nonetheless, it's kinda silly to be repeatedly calling SchedulePaint because we're obviously going to be doing a massive paint as soon as we're done with this massive reflow. (Also, we don't have any SVG rendering observers, which is what InvalidateDirectRenderingObservers is primarily concerned with.)
We should optimize this unnecessary work away somehow.
|
Reporter | |
Comment 1•2 years ago
|
||
Here's the profile in question, focused on "Category:Layout":
https://share.firefox.dev/3BqrQxy
This is a profile where I loaded the aforelinked testcase 3 times. The profile shows 10,999 samples inside of layout code, over those 3 loads.
If I then filter for "SchedulePaint", like so...
https://share.firefox.dev/3M5s5D9
...I get 3,895 samples (i.e. 35% of all of the time that we spend in layout code). That's mostly spent in InvalidateRenderingObservers.
Description
•