ccameron@ - any ideas?

No ideas offhand. brianderson, any ideas what that means?

Interestingly, it looks like there may have been a regression in the higher percentiles of our frame rate on MacOS going from M53 to M54:
https://uma.googleplex.com/p/chrome/timeline_v2/?sid=bd52cab2f94282449c407b8c16c537ec

There isn't a corresponding regression in the Renderer.SwapToAckLatency metric, so the browser's response to the Renderer's swap isn't likely the culprit.

It could be a number of other things though and this specific bug may not be reflected in UMA stats.

@directmusic: Can you attach a chrome trace of the slowness?

See: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

Also, does the slowness only happen with video? What use cases are slow for you?

Sounds like the LatencyInfo backup is a symptom, not a cause, most likely.

Are you able to reproduce this issue in Chrome Dev or Beta?

It seems to be happening with large websites in general, but it is very inconsistent. On the Youtube.com site the performance of the UI is incredibly slow and essentially unusable, but if I embed the video into a blank HTML file it seems to perform mostly normal.

I have attached the Trace file taken with 55.0.2883.35. I have also tested this on Chrome Canary and found the same result. If you need anything else such as chrome://gpu information let me know.

Deleted: trace_YoutubeLag.json.gz 7.3 MB

trace_YoutubeLag.json.gz 7.3 MB Download

@directmusic: Your mouse's sampling frequency is extremely high. Are you able to lower it or try with a different mouse?

@dtapuska: Do you think this could be related to the recent work that moved input even coalescing to the blink thread? (See graphs from #4 to see potentially when this may have regressed.)

I also wonder if this is a strange interaction with the blink scheduler giving too much priority to high frequency input events. (+skyostil and +alexclarke)

So the mouse events seem to be coming in at like 320Hz or so. 3ms apart. But it takes ~5ms to do the hit test and dispatch the event to the DOM.

RafAligned Mouse Input is designed to fix this problem but we aren't shipping that just yet.

What hardware mouse is this? We aren't seeing this with stock hardware on Mac I believe.

I am using a Logitech G303 mouse. I had it set to a polling rate of 1000. And while lowering it to 500, 250 and eventually 125hz it reduced the lag more and more. In fact, doing a lot of mouse movement on the page while at 1000hz then switching to 125 I can notice it catching up, so to speak. 500hz and 250hz are still extremely laggy.

Are you using any command line switches? From the trace I'm wondering if you have threading compositing disabled.

I am not at the moment. Simply launching via the dock. chrome://gpu says this for command line args:

Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --flag-switches-end

Does this trace have all categories enabled? I can't seem to find any logging of InputHandlerManager which is important to see.

I'm not seeing InputHandlerManager as an option to pick.

Can you provide a trace with all categories enabled?

The one I provided earlier had every category enabled. I have done another with the left column of categories enabled in the tracing dialog. Selecting all in the right panel of categories resulted in a failed import.

Deleted: trace_YoutubeLag2.json.gz 8.1 MB

trace_YoutubeLag2.json.gz 8.1 MB Download

Ok I'm certain I know what is going on.

Can you try executing:
defaults read -g NSScrollViewRubberbanding

from a shell and provide the result. Likewise could you execute
defaults delete -g NSScrollViewRubberbanding

and relaunch chrome and see if is improved?

Specifically threaded event handling is disabled on mac if you have rubberbanding turned off. I have no idea why see.. https://chromium.googlesource.com/chromium/src/+blame/master/content/renderer/render_view_impl.cc#1968

ccameron@ can we just remove this code?

The first command showed I did have it turned off with a value of 0. Running the second command fixed the issue. Thank you for spending the time on this.

I'll prepare a patch to remove the relevant code from checking that setting.

Patch posted for review: https://codereview.chromium.org/2489103002/

Thanks for figuring that out!

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

commit 2422a4e2a7e6b13b8ab3f817912032ba16c7bd73
Author: dtapuska <dtapuska@chromium.org>
Date: Wed Nov 09 21:46:10 2016

Don't disable threaded input handling if rubberbanding is disabled.

It appears this path of code was left in for when threaded input
handling was written for OSX. It ended getting adjusted to not
be based on a command line flag but eventually on a user setting.
Since threaded input handling works correctly even though rubberbanding
is disabled ensure that we always use threaded input handling.

This was a problem because when threaded input handling isn't used
every mouse move ends up generating a post event to the main thread
and the events don't get coalesced. This isn't really a concern
because threaded input handling is always expected to be enabled.

BUG= 662328 

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

[modify] https://crrev.com/2422a4e2a7e6b13b8ab3f817912032ba16c7bd73/content/renderer/render_view_impl.cc