roel@Could you please provide sample code or html file where you faced the issue with actual and expected behavior screencast for further triaging the issue.

We still require a reduction.

roel@ perhaps you could connect Max with this issue as he indicated in your  issue 4890 .

We require some reproduction or tracing in chrome itself.

Hi!

The part of our application that produces the behaviour is not easy for me to extract in a html file. 
What I can do for you:
1) Provide more detailed debugging/profiling information from within chrome (developer tools) if you guide me.
2) Show the problem live on my desktop with skype+teamviewer.
3) Setup a webserver running a demo of our application and give you the steps to reproduce.

Or something else if you have a better idea.

Thanks in advance and best regards,
Max

Please post a trace of the application behaving badly. Maybe that will give us a hint.

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

Hi! 

Please excuse the late answer.
Attached is a trace of the issue.

Thanks!

You had many tabs open when you recorded that trace. I assume the problematic one is the "ALEX" tab?

There was a lot of CPU activity from the process showing a Boston Globe article about Muhammad Ali, which may have inteferred.  

The stall in the "ALEX" tab is coming from ProxyImpl::ScheduledActionActivateSyncTree, so I am going to flag this as a compositor bug.  It would be very helpful if you did 3) so that we can reproduce the issue on our side.

Hi! 

Here the "cleaned" trace, without background noises.
Please excuse my first one.

I will prepare a test app for you to reproduce the issue and send you a description as soon as possible.

Deleted: trace_canvas_scroll2.json.gz 4.7 MB

trace_canvas_scroll2.json.gz 4.7 MB Download

Hi!

The test server is reachable under:

http://mail.bitfactory.at:9999/Alex

0) I made the test with a chromium window size of 1920x1080... 
1) Login with user: developer, pwd: developer.
2) click first entry in "zuletzt verwendet" in left pane, must be "Mai 2016, Abgeschlossen, 1_VERKAUF PLANUNG" and wait for grid to load.
3) Scroll the grid with the scrollbar on the right side. -> slow!

I've included a couple of traces from my runs. It clear shows that the BeginMainFrames take like 136ms and that seems to be the cause of the slow scrolling. 

Removing the scrolling component as this seems to be a compositing issue.

Deleted: trace_compositing_trace.json.gz 5.1 MB

trace_compositing_trace.json.gz 5.1 MB Download

Deleted: trace_input_latency.json.gz 626 KB

trace_input_latency.json.gz 626 KB Download

From the traces, it looks like this could be caused by a scheduling experiment that starts the main frame before activation. See  issue 612596 .

Marking as a potential blocker for  issue 612596 .

If you run with the --disable-main-frame-before-activation command line flag, does it improve?

Hmm. I was looking at the traces in #11, but the traces in #8 look completely different. Sunny also mentioned that the scheduling experiment isn't active on the M50 branch, which this bug is filed against - so I'm unblocking  issue 612596 .

From the trace in #8, simply activating the pending tree takes an entire second for some of the frames. +vmpstr in case he's seen this before.

Each of the canvases is being promoted to a layer, so this page has thousands of composited layers. Most of the canvases are small (e.g. 171x40, 20x20, etc.).

Justin, are these small canvases meant to be composited? Did we change canvas compositing reasons between Chrome 49 and Chrome 50?

I think this bug justifies revising the layer promotion heuristic.  I'll take it.