Confirmed the page feels unusually janky on 55.0.2859.0. Attached trace shows frequent ~15ms hit tests, ~25ms compositing updates, and ~13ms paints with occasional very long (~330ms) invalidations. Doesn't look like we're creating many layers in DevTools but we're definitely exploding some data struct on this extremely large page.

Over to paint team for someone there to take a look.

Deleted: trace_janky_scroll.json.gz 2.7 MB

trace_janky_scroll.json.gz 2.7 MB Download

It's scrolling at about 10-15 fps for me, according to DevTools, with no major lags on Win 7, 54.0.2840.27 beta-m.

Canary also seems OK to me, apart from a little initial jank.

Passing along to wangxianzhu@ given the invalidation cost in the trace. But I'm not sure this is actionable and not something to be fixed when we enable compositing of opaque scrollers in an upcoming release.

Interestingly, if you turn on Paint Flashing in DevTools we must start compositing the scroller because it jumps to 60fps and we don't repaint. There's something really odd there.

I think we can skip investigation on the main-thread scrolling path for the case. 10-15 fps for the slow path seems acceptable. We should investigate how to enable fast path for the case and performance issues of the fast path instead.

Tried --enable-prefer-compositing-to-lcd-text and collected a trace. The trace shows the following performance issues:
- Some times there are 2 hit tests (each 15~20ms) in one frame cycle.
- Compositing update is slow (each 30~40ms).

Possible TODOs:
- investigate what prevents us from using composited scrolling;
- investigate the performance issues of compositing update.

I'm lowering the priority because we might not address these issues on SPv1. We should definitely check performance of SPv2 for this case.

DevTools shows 60fps with Paint Flashing, but trace shows the average frame time is the same, so DevTools is showing false fps with Paint Flashing. Will file another bug for it.

Deleted: trace_github-composited-scroll.json.gz 1.4 MB

trace_github-composited-scroll.json.gz 1.4 MB Download

 Issue 665223  has been merged into this issue.

Created a reduced test case. You can scroll it and capture trace, or put it into third_party/WebKit/PerformanceTests/Paint and it will test automatically and give report.

There is a fixed-position element and many small layers.

Deleted: fixed-and-many-layers-scroll.html 639 bytes

fixed-and-many-layers-scroll.html 639 bytes View Download

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

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm tempted to WontFix this now. The page scrolled fine for me just now.

Add your thoughts or just WontFix it.