I can't repro on Linux. Could you please attach a trace:

https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

Of course, please find it attached. I hope it helps. If you need more information, please let me know.

Deleted: trace_trace.json.gz 5.5 MB

trace_trace.json.gz 5.5 MB Download

Thanks.

Looks like we're repainting on scroll. But the fact you say its worse that in 61 says to me something else degraded. Looking at a typical frame, it looks like Compositing and Painting are taking a really long time.

PLC::UpdateIfNeededRecursive is taking about 4ms which is long but I don't know how bad that is. But LocalFrameView::PrePaint takes almost 8ms and PaintTree takes 5ms so it seems like we're hitting a really bad case for those methods.

Over to paint team to take a look.

mehmet@ Thanks for the issue.

Unable to reproduce the issue on Mac OS 10.12.6, Windows 7 and Ubuntu 14.04 using the latest Canary 63.0.3230.0 and latest Stable 61.0.3163.100  with the below steps.

1. Launched Chrome and navigated to the above given link - https://news.google.com/
2. Launched the Activity Monitor on Mac and observed the CPU usage on scrolling the Google news page.
Could observe that the CPU usage is less and scrolling on the google news page is smooth.

Attached is the screen cast for the same. Please confirm if anything is missed here.

Request you to please retry the issue on a new Chrome profile without any flags/extensions and update the thread if there is any issue.

Thanks...

Deleted: 770817.webm 5.0 MB

	770817.webm 5.0 MB View Download

mehmet@, what specific hardware is this on? High DPI and regular displays will have different behavior.

susanjuniab@: I can reproduce it with a new profile, too. 

schenney@: I am using a MacBook Air 11 Non-Retina regular display Mid 2012. I see this also on my Non-Retina regular display iMac 21.5 End 2012. 

Unfortunately I do not have a Retina Mac to test it.  

Thanks. 

On a non retina display we do not composite the scroller, so we do paint it each frame. It may be possible to reproduce using a normal resolution monitor attached to any mac.

Over to the Invalidation folks as that seems to be taking a lot of time, unless I'm mistaken about what the pre paint walk does.

I just tried 61.0.3163.0 on Linux and got the same trace as #c2, and I saw no difference between 61.0.3163.0 and ToT. The scrolling is not composited in both versions.

mehmet@ can you attach a trace for m61 on your machine?

wangxianzhu@: Of course, here it is from Chrome M61 Stable. Thanks.

Deleted: trace_trace_M61.json.gz 6.9 MB

trace_trace_M61.json.gz 6.9 MB Download

Thanks metmet@ for the traces.

I compared the two traces. Both M61 and M63 use non-composited scrolling. There is no obvious difference about CPU usage. However, almost all steps ran slower in M63 than in M61 based on the traces. During scrolling:

                    M61      M63
BeginMainFrame     14ms     21ms
PrePaint           5.6ms    7.7ms
PaintTree          2.4ms    3.8ms
CompositingUpdate  3.8ms    6.3ms

mehmet@ are you using the same build configuration for M61 and M63, e.g. both are 64bit official builds without dcheck on? Did you start to run when the system was idle?

wangxianzhu@: Thanks for checking it. I am using a regular Chrome 61 Stable and a Chrome Canary 63 build. Both builds are running in 64Bit without dcheck on. Yes, I createad both traces in the same way (every other app was idle). It is not only on Google News, where I am noticing the „heavier“ scrolling. I am seeing it also on other pages :-(

One question is if some field trial could be the cause. A quick way to tell would be to run both versions of Chrome with a new user data dir (via --user-data-dir=/some/path), using a new directory for each. With a new user data dir, you won't have field trials downloaded from the server yet on the first run - so it will use default configurations for them. Can you try that and see if you still get the same results?

asvitkine: Thank you. Yes, starting Chrome Canary via --user-data-dir= fixes the problem. Scrolling is then much better again and the CPU usage during scrolling is the same as in Stable. So it seems, that this is caused may be by an experiment?

Here is my variations from about:version:

c134752e-b8b72c88
fe69e053-d93a0620
da89714-4ad60575
241fff6c-ec1be22a
1e528f0f-f23d1dea
b130ecb8-1410f10
6025934e-3f4a17df
7c1bc906-86bf56d9
47e5d3db-3d47f4f4
1c752ce9-30f1ce65
79616653-3f4a17df
19c1fdaf-ca7d8d80
3042ad4b-f23d1dea
9e201a2b-38d7ffb9
44c96c7b-7968b21c
68812885-4d2fac87
332a4d9b-e4165b4e
b684f56f-3f4a17df
b72f69e9-3f4a17df
4b61504a-dd106449
5485fc4d-ca7d8d80
9773d3bd-cc03d394
9e5c75f1-38e1c567
e79c5ffa-3f4a17df
f79cb77b-3d47f4f4
ab7c3406-f23d1dea
4ea303a6-385dee18
12be2281-f23d1dea
d92562a9-3d47f4f4
1aecb842-3f4a17df
1bced4a3-a3fca1da
4932440-f23d1dea
757a5d98-ca7d8d80
23496387-1b127e42
796ee5fe-f23d1dea
b2f0086-3f907e47
ef25c1eb-3f4a17df
4bc337ce-a6528b4d
3ac60855-486e2a9c
f296190c-a2200d3b
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-a5822863
e7e71889-4ad60575
f5fff3a2-3f4a17df
bbb8f811-3f4a17df
94e68624-f23d1dea
f141d4bc-f23d1dea
11d91db8-3f4a17df
828a5926-8f2c913
9cade933-f23d1dea
da4aaa01-3f4a17df

asvitkine@, how do we map these back to experiments? I just realized we recently turned on a scroll related experiment and now I'm wondering if maybe it's responsible.

You can map them back using the internal go/variations-hashes tool.

mehmet@ can you paste the variations of both the configuration reproducing this bug and the good configuration?

wangxianzhu@: Of course, please find both attached.

Deleted: good_Chrome_Stable_61.rtfd.zip 2.4 KB

good_Chrome_Stable_61.rtfd.zip 2.4 KB Download

Deleted: bad_Chrome_Canary_M63.rtfd.zip 2.5 KB

bad_Chrome_Canary_M63.rtfd.zip 2.5 KB Download

mehmet@ thanks for the files. However, it's not easy to find the culprit because there are too many different variations between M61 and M63. Can you run Canary M63 with and without --user-data-dir, and make sure the former is good and the latter is bad, and paste the variations parts of them here (instead of zipped rtf files)?

wangxianzhu@: Enclosed both variation:

*** This one is the good from latest Canary:

c134752e-f23d1dea
fe69e053-f23d1dea
da89714-473c5974
241fff6c-92b34125
1e528f0f-f23d1dea
b130ecb8-2e32ee7e
6025934e-3f4a17df
7c1bc906-b5809d46
47e5d3db-3d47f4f4
1c752ce9-ca7d8d80
776de70c-e0278d3d
79616653-3f4a17df
19c1fdaf-ca7d8d80
3042ad4b-f23d1dea
9e201a2b-38d7ffb9
44c96c7b-f23d1dea
68812885-4d2fac87
332a4d9b-5e11c051
b684f56f-3d47f4f4
b72f69e9-3f4a17df
4b61504a-90ff5fb9
5485fc4d-ca7d8d80
9773d3bd-720b026c
9e5c75f1-77b2f434
e79c5ffa-f23d1dea
f79cb77b-3d47f4f4
ab7c3406-3f4a17df
4ea303a6-fcb21446
12be2281-3f4a17df
d92562a9-ca7d8d80
1aecb842-f23d1dea
1bced4a3-a3fca1da
4932440-d21eb72d
757a5d98-f23d1dea
23496387-232b3cab
796ee5fe-f23d1dea
b2f0086-d3486be4
ef25c1eb-3f4a17df
4bc337ce-cf4f6ead
3ac60855-486e2a9c
f296190c-7158671e
4442aae2-d7f6b13c
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-cdc3d902
e7e71889-e1cc0f14
f5fff3a2-f23d1dea
bbb8f811-f23d1dea
94e68624-3f4a17df
f141d4bc-f23d1dea
11d91db8-f23d1dea
828a5926-c6c0a780
da4aaa01-3f4a17df


*** This one is the bad from latest Canary:

c134752e-b8b72c88
fe69e053-d93a0620
da89714-5e283afd
241fff6c-92b34125
1e528f0f-f23d1dea
b130ecb8-1410f10
6025934e-3f4a17df
7c1bc906-b5809d46
47e5d3db-3d47f4f4
1c752ce9-30f1ce65
79616653-3f4a17df
19c1fdaf-ca7d8d80
3042ad4b-cf4f6ead
9e201a2b-38d7ffb9
44c96c7b-7968b21c
68812885-4d2fac87
332a4d9b-e4165b4e
b684f56f-3f4a17df
b72f69e9-3f4a17df
4b61504a-dd106449
5485fc4d-ca7d8d80
9773d3bd-7c7ea110
9e5c75f1-2ba0db49
e79c5ffa-3f4a17df
f79cb77b-3d47f4f4
ab7c3406-f23d1dea
4ea303a6-169d98df
12be2281-f23d1dea
d92562a9-4e0e29ca
1aecb842-3f4a17df
1bced4a3-623dd002
4932440-f23d1dea
757a5d98-f23d1dea
23496387-1b127e42
796ee5fe-cf4f6ead
b2f0086-3f907e47
ef25c1eb-3f4a17df
4bc337ce-a6528b4d
3ac60855-486e2a9c
f296190c-a2200d3b
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-a5822863
e7e71889-4ad60575
f5fff3a2-f23d1dea
bbb8f811-3f4a17df
94e68624-f23d1dea
f141d4bc-f23d1dea
11d91db8-3f4a17df
828a5926-8f2c913
9cade933-f23d1dea
da4aaa01-f23d1dea

Please see the attachment for all differences between good and bad.

I think this is not related to paint. bokan@, can you check if this is related to the scroll experiment?

Deleted: diff-good-bad.txt 3.3 KB

diff-good-bad.txt 3.3 KB View Download

The "Bad" version is in the WheelScrollLatching experiment while the "Good" isn't but "bad" is in the control group which means the two should be running in the same configuration.

+sahel@ to double check. Could you take a look at the two traces and see if you can confirm that latching is off in both?

Ping.

The traces don't have input events, so I couldn't confirm situation of latching on them. But as bokan@ mentioned the "bad" version is in control group of the wheel scroll latching experiment which means it is the same as M61 stable.

mehmet@ could you please try to reproduce the bug with explicitly enabling and disabling the wheel scroll latching and async wheel events runtime flags:
--enable(disable)-features=TouchpadAndWheelScrollLatching,AsyncWheelEvents

Hello sahel@,

I tried it in Canary 64.0.3251.0 with

--enable-features=TouchpadAndWheelScrollLatching,AsyncWheelEvents

and

--disable-features=TouchpadAndWheelScrollLatching,AsyncWheelEvents

Both flags have the same result/effect: an higher CPU-Usage during scrolling with Canary 64 compared to Stable 62.

Please let me know, if you need more information.
Thanks.

I just compared again the good and bad traces, and found that in the bad trace, the rasterizer threads were busier. It seems that we were rasterizing more tiles.

mehmet@ can you capture two traces, both on M64, one with --user-data-dir and one without, by selecting "Frame Viewer" in "Record a new trace..." dialog?

wangxianzhu@: Please find two links to the requested traces. They are so large that I had to save them in GDrive.

good: https://drive.google.com/open?id=0B5yiCVqGKvIjM282TXRTUTNuUUE

bad: https://drive.google.com/open?id=0B5yiCVqGKvIjTlAydV9pS282TjQ

I hope they will help you. Thanks!

Thanks for the traces. In the bad trace, rasterizations were by CPU, while in the good trace were by GPU. Based on the diff in #c21, the following experiments should be related:
-DefaultEnableGpuRasterization-Default
+DefaultEnableGpuRasterization-DisabledHoldback3

You are lucky to be chosen for non-GPU rasterization experiment :)

Given that experiment is causing bad experience like this, should we consider shutting it down? What value is it bringing to keep running?

We've kept this holdback group on in order to diagnose whether UMA regressions are due to GPU raster or not. It's only enabled on Canary, and has been helpful in figuring out a few memory issues. That said, as time goes on the benefits do keep shrinking. I'd be open to shutting it off at this point. I'll put together a CL.

Thanks. Confirming that "enabling" the flag "DefaultEnableGpuRasterization-Default" in about:flags is reducing the CPU-usage during scrolling on different websites and makes scrolling much smoother again.