It seems we are doing very poor job keeping track of slight regressions
over time.

The performance characteristic (single tab on new browser is laggy,
while multiple tabs or multiple browsers are relatively smoother) is interesting.

If you have any insight already about which part regressed most, or which is
blocking it from animating smoothly, it would be very helpful.

When I ran the page on my MacBook Pro with task manager, the Tab is using
~100% of CPU, and browser process 20-50%, GPU process 80%. So definitely
there are some bottleneck in the main application tab, and would be worth
taking a look at performance graph in the developer tool to identify what is
the most significant blocker.

Adding 'Needs-Milestone' label, TE will check the issue and update the bug with comments & tag with respective Mstone

andyfoulds12@, could you take some time to record a performance tracing
for analysis by developers?

http://dev.chromium.org/developers/how-tos/submitting-a-performance-bug
describes how to record a performance log on your Chrome browser (developer
tools).

If you could take both (one for new-browser,new-tab and the other for
multi-tab) profiles, it would be very helpful to analyze what are going on.

Thanks!

Couldn't repro this behavior on linux M54 (it's consistently jittery).

On mac M55 and M57 I don't see any difference between a fresh chrome instance and several tabs open, however my macbook is consistently smoother.

On linux we're gpu bound with massive 150ms pauses in between while on mac I see only max 10ms pauses.

I cannot reproduce the behavior on a windows laptop either (M56 and M57)

Looking at a timeline recording in DevTools I see 30% of the time spent in drawImage, another 5.7% in transform. Summing all those items up yields ~57% of the time spent in drawing primitives. So from a JS programming point of view this looks good, also there are very few IC-misses and very few deopts.

In conclusion, this is probably not a JavaScript issue but related to rendering.

cbruni@ thanks for the investigation on JavaScript side.

@andyfoulds12@, still we appreciate if you could post your trace data
when you encounter the sluggishness.

Extending the next action date as it's holiday season.

Apologies for the late reply.. away. Thanks for your attention. I'm pleased
to learn that the cause is probably not my coding :)
I have the jittery, laggy playback at all times as - if compared to Chrome
of around the mid-thirties versions of when this site was first produced -
the playback has progressively degenerated with each update until it has
reached the point that the other major browsers are the same or better.

Hi, I'm not sure why your comments got deleted, but I did get to read them via e-mail notifications.  The team has just been very busy lately, but were are taking this issue seriously.  

It appears that the GPU rate-limiter mechanism is kicking in in situations where it should not.  The problem is exacerbated on platforms with OpenGL drivers that do not support sync queries.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ac0ae9669662fadaf27f247d0c46d6e14e075fe

commit 9ac0ae9669662fadaf27f247d0c46d6e14e075fe
Author: junov <junov@chromium.org>
Date: Wed Feb 22 16:03:54 2017

Simplify rate limiter logic in Canvas2DLayerBridge

This CL is a follow-up to https://codereview.chromium.org/2653933003/.
It refactors the rate-limiter code to make it stop using it own task
observer, in favor of piggy-backing on top of the finalize frame signal

BUG= 653548 , 673469 

Review-Url: https://codereview.chromium.org/2700833002
Cr-Commit-Position: refs/heads/master@{#452071}

[modify] https://crrev.com/9ac0ae9669662fadaf27f247d0c46d6e14e075fe/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/9ac0ae9669662fadaf27f247d0c46d6e14e075fe/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h

Thank you for your time. I look forward to Chrome regaining it's crown :)