ecma262 spec has horrible scrolling performance without will-change: transform |
|||
Issue descriptionVersion: 56.0.2919.0 canary (64-bit) OS: Windows 10, Mac, Linux What steps will reproduce the problem? 1. Navigate to https://tc39.github.io/ecma262/ 2. Open devtools, and edit the #spec-container element (directly under body) by removing the `will-change: transform;` style 3. Scroll around, either using PageUp/PageDown, the mouse wheel, or the scrollbar What is the expected result? Scrolling should be buttery smooth, like it is in Firefox, Safari, and Edge (without will-change: transform). What happens instead? Scrolling is very laggy, with (on my beefy desktop) two 170-190 ms frames per pagedown keypress. The devtools timeline view says all this time is spent in "Update Layer Tree". I've attached a trace (not sure I did that right) and a devtools timeline export, taken in separate instances. ---- This cost the developer (bterlson, CC'ed) a few hours of debugging work. It was especially difficult since on his computer, the scrolling was smooth without the will-change: transform. We only reached that via him changing various things and then asking me to test. All other browsers are able to handle this fine. Some other interesting modifications you can make, after removing `will-change: transform`: - Removing `position: absolute` + `overflow: hidden` on the body makes scrolling fast again (at the expense of messing up the page layout a bit) - But then adding `height: 100vh` will make the page slow again.
,
Nov 18 2016
Setting background: white on the #spec-container element will cause fast
composited scrolling at ToT, because now it's opaque. But this bug is really
about why the compositing update step ("update layer tree") is so slow here.
Looking..
,
Nov 18 2016
It's paint invalidation that is so slow here.
,
Nov 18 2016
The reason paint invalidation is slow is that in the slow-scrolling path, we force paint invalidation for the scroller and all descendants. The way this is done is to recurse into all of them and update their visual rects, then invalidate those visual rects. See: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp?q=paintlayerscrollablearea.cpp&sq=package:chromium&dr&l=440 SPv2 is going to address this.
,
Nov 23 2016
Just updating the repro URL: https://bterlson.github.io/ecma262/.
,
Mar 1 2017
,
Mar 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fd7fc207884807c1b5365c191cf6d5cb55e33f4c commit fd7fc207884807c1b5365c191cf6d5cb55e33f4c Author: wangxianzhu <wangxianzhu@chromium.org> Date: Thu Mar 02 02:13:30 2017 Add several tough paint performance tests These tests are based on the test cases in the bug reports to demostrate slow compositing, paint invalidation and perhaps also painting. BUG= 646719 , 665223 , 692614 Review-Url: https://codereview.chromium.org/2723243002 Cr-Commit-Position: refs/heads/master@{#454152} [add] https://crrev.com/fd7fc207884807c1b5365c191cf6d5cb55e33f4c/third_party/WebKit/PerformanceTests/Paint/complex-content-slow-scroll.html [add] https://crrev.com/fd7fc207884807c1b5365c191cf6d5cb55e33f4c/third_party/WebKit/PerformanceTests/Paint/containment-resize.html [add] https://crrev.com/fd7fc207884807c1b5365c191cf6d5cb55e33f4c/third_party/WebKit/PerformanceTests/Paint/fixed-and-many-layers-scroll.html
,
Mar 3 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by schenney@chromium.org
, Nov 18 2016