Tried a repro of this on Windows-10 and below are the observations from different chrome versions and Firefox:

50.0.2646.0 - FPS varies from 56-58 on mouse wheel up and down.
62.0.3202.62 - FPS varies from 53-55 on mouse wheel up and down.
63.0.3239.9 - FPS varies from  59-63 on mouse wheel up and down.
64.0.3249.2 - FPS varies from 80-90  on mouse wheel up and down.
Firefox -  FPS varies from 115-123 on mouse wheel up and down.

devguider@: Could you please confirm these behavior and any reference value when it used to work fine on Chrome.

 

Hello,
implemented FPS counter didn't change because screen is stuck. When you using mouse wheel up and down and look at it hexagons animations not smoothly show/hide if you release scrolling all it's work fine.

Thank you for providing more feedback. Adding requester "ajha@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Tested on Chrome Stable #62.0.3202.75, Canary #	64.0.3254.0 on Windows 10 & Ubuntu 14.04 and able to reproduce the issue.
 
Please find the bisect info below:
Chrome Good Build - 51.0.2694.0 (383878)
Chrome Bad Build - 51.0.2695.0 (384157)

Per-revision bisect and hasbisect did not provide any possible suspects, so providing the CL manually.
 
Below is the CL: https://chromium.googlesource.com/chromium/src/+/4dd0a0e74bb425445036920817a903b0733db4e4

Review URL: https://codereview.chromium.org/1839213003

@yusufo -- Could you please look into the issue, pardon me if it has nothing to do with the above changes and if possible please assign it to concern owner.

Note: 
1. Assigning it to yusufo@ as ianwen@ seems to be away when tried to assign.
2. Per-revision bisect provided all good builds even after increasing the range.
3. Unable to reproduce this issue on Mac 10.12.6.

Thanks.

Pinging composited scrolling folks.  Is this intended behavior? Are we deliberately suspending animations while mousewheeling?

Well the delay was added for UI animation purpose and it has nothing to do with mouse or wheel or scroll. If you see the CL, a fixed delay was added when we start another animation.

Also typically speaking android animations should never interfere with rendering the web content. We use SurfaceView and it's drawing cycle is independent of Android UI thread.

This is definitely not related to Android changed. However, I no longer seem to be able to reproduce on canary on Linux (68.0.3432.3). I was able to reproduce on stable (66.0.3359.117). I ran a bisect and got:

Revision 557929 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
You are probably looking for a change made after 557929 (known bad), but no later than 557940 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/6d6b03409b44d9df4854e3d3d4ee0f51e95fa642..e45bf8e41c7786a1592ff3ab8e259e39dded76d4


I'm not 100% sure which of those changes may have fixed it, but cc-ing sahel@ for ea218ea as it might have been related. sahel - do you think your scrolling change could have fixed the stuttering that was seen in the repro? (Open file in #1, do a mouse-wheel scroll. In stable you should see the animations in the canvas stutter really badly. Note sometimes you do have to refresh the page and try again to reproduce).

In any case, since I can't reproduce on canary I intend to close this once sahel@ has commented.

Sahel never commented, but that canary version (M68) has come and gone as a stable version (we're now on M69) and the problem appears to still be fixed. Closing.