1344531 - Page rendering is slow after change css(such as overflow hidden and/or auto)

Status: RESOLVED DUPLICATE of bug 575614

(Core :: Layout, defect)

Description

[Alice0775 White]

+++ This bug was initially created as a clone of Bug #1344157 +++


Page rendering is slow. It happens with/without e10s.
And browser becomes unresponsive for super long period if a11y is activated(ATOK IME) .

Steps to reproduce:
1. Open https://en.wikipedia.org/wiki/United_States
2. Evaluate the following code in web console
        document.body.style.setProperty("overflow-y", "hidden", "");
--- observe page rendering
3. Evaluate the following code in web console
        document.body.style.setProperty("overflow-y", "auto", "");
--- observe page rendering


Actual Results:
Page rendering is super slow

Expected Results:
It should be short period like Chrome


Gecko Profiler log:
https://perf-html.io/public/99e78c727fe8ef102b47eecb09f61d54cd1672f2/calltree/?thread=0

Comment 1

[Mats Palmgren (inactive)]

Daniel is investigating the slow restyling issue in bug 1344398.

The "if a11y is activated" condition here seems a bit odd though,
it sounds like a separate issue.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #1)
> The "if a11y is activated" condition here seems a bit odd though,
> it sounds like a separate issue.

The a11y stuff here is basically in the same issue.

Right now, when we reconstruct frames (as we do for this bug's STR right now), we also reconstruct the accessible associated with those frames -- that likely explains why we spend extra time on this when a11y is activated.  Bug 1285862 is filed on improving the situation there.  And as mats said, bug 1344398 covers the fact that we're reconstructing frames here at all.

Comment 3

[Daniel Holbert [:dholbert]]

Here's a profile of Step 3 of this bug's STR, using up-to-date mozilla-central enable-debug enable-optimize build:
https://perf-html.io/public/5e35e9469049357151b2950e37578cdb3a82689a/calltree/?thread=2
--> 7 seconds of jank (split into a ~0.8 second chunk and a ~6.4 second chunk, and the latter chunk is nearly all reflow)

...and here's a profile if I tweak nsStyleDisplay::CalcDifference so that "overflow" & "position" changes simply trigger nsChangeHint_AllReflowHints rather than nsChangeHint_ReconstructFrame (simulating the state after "overflow" changes are handled more cheaply):
https://perf-html.io/public/ae2bd605debc05fc6b66539799e25d49f70518bb/calltree/?thread=2
--> 0.8 seconds of jank (nearly all reflow)


0.8 seconds of jank is still not great, but it's way better than 6-7 seconds.

Conclusion: if we make "overflow" changes trigger reflow instead of frame-reconstruction, things get much faster on this Wikipedia testcase.

Comment 4

[Daniel Holbert [:dholbert]]

(And actually, I'm realizing that the "if a11y is activated [...] browser becomes unresponsive" symptom is probably explainable by the fact that a11y tools cause e10s to be disabled.  And if e10s is disabled, then page-layout-jank [as experienced here] will hang the browser frontend.)

Comment 5

[Daniel Holbert [:dholbert]]

In a local linux opt build with default profile configuration (with e10s, without a11y tools active): my current patch stack on bug 1344398 gives a 35-40% reduction in the Gecko-Profiler-reported tab-processing-delay time, with comment 0' STR (specifically, when going from unset to "hidden").

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] (reduced availability - travel & post-PTO backlog) from comment #3)
> Conclusion: if we make "overflow" changes trigger reflow instead of
> frame-reconstruction, things get much faster on this Wikipedia testcase.

Sadly, "much faster" may have been an overstatement here. :-/  Even though we're no longer reconstructing the world, we're still reflowing the world, which is slow here.

(We have to reflow the world because hiding/showing the scrollbars is roughly equivalent to a horizontal window-resize, because the scrollbars occupy some horizontal space.)

So the remaining issue here is that incremental reflows of this page are still quite slow.  For example, the following two tweaks each take about 1 second to perform in the web console:
 document.body.style.overflow = "hidden"
 document.body.style.width = "95%"
...as does a horizontal window-resize.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] (reduced availability - travel & post-PTO backlog) from comment #6)
> So the remaining issue here is that incremental reflows of this page are
> still quite slow.

...which is bug 575614.  Since that's responsible for most of the original slowness here & all of the remaining slowness (I think), I'm going to dupe this to bug 575614.