Probably this needs some more information (e.g. tracing log?) for investigation.
Can someone in Blink>Scroll give any advice what to look at?

If there is something further I can provide, let me know and I will do my best to provide this for you.

Thank you for providing more feedback. Adding requester "kochi@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

Please provide
1) the URI you are encountering this on?
2) An input latency trace for the duration of the scroll.

Attached is the trace requested. As I mentioned, it is not specific to a specific URI, but for this trace, I have selected:
https://www.google.com/intl/en/about/

Deleted: trace_input.latency.json.gz 933 KB

trace_input.latency.json.gz 933 KB Download

Thank you for providing more feedback. Adding requester "dtapuska@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

Thanks. The DrawAndSwap seems to take like 158ms or. Are you able to provide a Rendering trace this time?

It doesn't seem related to the input latency of the scroll events but the GPU pipeline is really slow.

Please see attached. I used the same URI. Hardware is older hardware, I can send detail if it might help if you cannot get from my submission through Chrome. Upgrade to v59 is the first experience of any issues if hardware is the cause.

Deleted: trace_rendering.json.gz 2.9 MB

trace_rendering.json.gz 2.9 MB Download

It is all software rendering.

Title	SoftwareRenderer::FinishDrawingFrame
Category	cc
User Friendly Category	other
Start	
8,724.317 ms
Wall Duration	
77.128 ms
CPU Duration	
3.083 ms


Can you give the details of chrome://gpu? Sending over to the compositing team.

Please see attached.

Deleted: chrome.gpu.txt 4.9 KB

chrome.gpu.txt 4.9 KB View Download

I have visited this site:
https://www.carid.com/articles/what-type-of-body-kit-material-should-i-choose.html.
On this page, the choppy scrolling is really bad. It is also bad on ebay pages, this as an example:
http://www.ebay.com/itm/231846238045.
The exact URIs I listed, I have not visited prior, but I share as an example of page that is one of the worst. I am hoping it may help.

As I post the above, I notice that scrolling on this very page is also quite choppy:
https://bugs.chromium.org/p/chromium/issues/detail?id=716949&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

Hello- I did a new Rendering Trace on this page:
https://www.nytimes.com/2017/05/02/world/asia/navy-south-china-sea.html

I did this to give you one for a page that was really bad. Additionally, I have found this issue to be worse on 2 criteria:
1) The longer Chrome is open. This can be helped by closing Chrome completely and then reopening. I have noticed that Hangouts extension takes a very long time to close when doing this. When the issue is not there, Hangouts closes quickly with the rest of Chrome.
2) There are other things besides Chrome open. For example, I was watching a movie when this last one happened. The movie was on pause.

This trace was also done with the Chrome the way I would normally use it, with extensions running. The others I provided in incognito mode. I have seen no difference between using incognito or not, so I hope this is ok.

Deleted: trace_trace.json.gz 1.8 MB

trace_trace.json.gz 1.8 MB Download

I'll take this to investigate more.

I wonder if we're now blacklisting all GPU features by switching to SwiftShader when WebGL is unsupported.

Thanks for the reply. After reading your response, I did some looking and have attached a portion here of my xsession-errors log:

[25124:25124:0505/150426.818304:ERROR:gl_implementation.cc(246)] Failed to load /opt/google/chrome-beta/swiftshader/libGLESv2.so: /opt/google/chrome-beta/swiftshader/libGLESv2.so: cannot open shared object file: No such file or directory
[25124:25124:0505/150427.506104:ERROR:gpu_child_thread.cc(174)] Exiting GPU process due to errors during initialization
[25133:25133:0505/150427.683406:ERROR:gl_implementation.cc(246)] Failed to load /opt/google/chrome-beta/swiftshader/libGLESv2.so: /opt/google/chrome-beta/swiftshader/libGLESv2.so: cannot open shared object file: No such file or directory
[25133:25133:0505/150427.686806:ERROR:gpu_child_thread.cc(174)] Exiting GPU process due to errors during initialization
[25143:25143:0505/150427.786057:ERROR:gl_implementation.cc(246)] Failed to load /opt/google/chrome-beta/swiftshader/libGLESv2.so: /opt/google/chrome-beta/swiftshader/libGLESv2.so: cannot open shared object file: No such file or directory
[25143:25143:0505/150427.809288:ERROR:gpu_child_thread.cc(174)] Exiting GPU process due to errors during initialization
[24878:24916:0505/150431.553945:ERROR:service_manager.cc(425)] InterfaceProviderSpec prevented connection from: content_utility to: content_browser
[24878:24916:0505/150432.457544:ERROR:service_manager.cc(425)] InterfaceProviderSpec prevented connection from: content_utility to: content_browser
[24878:24916:0505/150432.570513:ERROR:service_manager.cc(425)] InterfaceProviderSpec prevented connection from: content_utility to: content_browser
[24878:24916:0505/150432.771433:ERROR:service_manager.cc(425)] InterfaceProviderSpec prevented connection from: content_utility to: content_browser
[24878:24916:0505/150433.017769:ERROR:service_manager.cc(425)] InterfaceProviderSpec prevented connection from: content_utility to: content_browser
[24878:24878:0505/150500.865162:ERROR:display_info_provider_aura.cc(31)] Not implemented reached in virtual void extensions::DisplayInfoProviderAura::UpdateDisplayUnitInfoForPlatform(const display::Display &, extensions::api::system_display::DisplayUnitInfo *)

I might be having the same problem in https://bugs.chromium.org/p/chromium/issues/detail?id=719213 - my newer Mesa drivers were blacklisted, maybe unintentionally

It's indeed the case that if the GPU does not reliably support WebGL 1, we're now blacklisting the GPU for all purposes. Considering that OpenGL ES 2.0 just celebrated its 10th birthday, this seems quite reasonable. Of course it means that systems which were too aggressively/conservatively blacklisted for WebGL are now affected more broadly.

That said, the performance of compositing on the CPU should still be very acceptable too. But when I run a recent build on a single core of my Linux workstation (taskset -c 0 out/Release/chrome --disable-gpu), I do observe some unexpected choppiness. In fact it looks like the frames jump forward, then backward, then forward again. On Windows, also using one core, things look much better.

So to clarify... starting with Chromium 59, newer hardware is now required? This seems odd as I have a bunch of systems in business use, using GIMP, Scribus, Inkscape, etc on a daily basis that work with no problems at all. I do not see a reason to upgrade them just to use Chromium to browse the internet when Firefox and Opera will work without problem. Especially since you cannot just upgrade video on a laptop, but need to replace the whole thing.

The hardware in use that has this issue is a dual core 2GHz. Could you recommend a method to avoid such issues on a machine like that? This one is a GPU Intel 945GM, most others are a 965, but I have a mix. The standard is a dual core 2-2.4GHZ with 4GB RAM, in some cases that 4GB is only 3.2GB usable though. If I can disable HTML5 from auto playing, that would be great too, all of that stuff is simply not wanted unless specifically asked for by hitting play.

No, you don't strictly need newer hardware. We'll just use the CPU for rendering instead of the GPU. The Intel 945GM is very unreliable. See for example  Issue 232035 . Firefox also doesn't support it: https://bugzilla.mozilla.org/show_bug.cgi?id=623107. And Intel discontinued all support for the 945GM on May 27, 2016.

However, the CPU rendering path appears to be affected by a bug itself, which is making things appear choppy. This needs further investigation.

Ok, thank you for the info. That would work just fine for me. Once the bug is corrected, will there by anything needed on the settings side? I am more than happy to test.

capn@: What I'm noticing is that we're not v-synced in software compositing, but I'm not able to reproduce the forward-then-backward jumpiness you saw in #20.

vmiura@: It's not very perceivable to me on a page like https://www.nytimes.com/2017/05/02/world/asia/navy-south-china-sea.html, but on for example https://webglsamples.org/aquarium/aquarium.html with the maximum number of fish (so on a single core it only renders at 2 FPS) there's a very annoying flicker between every frame that I can only describe as going forward-backward-forward.

When I do "nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceCompositionPipeline = On }" it's gone but I can still see regular, much less annoying V-sync tear.

It could be driver specific of course. I have a Quadro K2200 with NVIDIA 367.57 drivers.

Ubuntu's default Unity desktop comes with a compositor that sometimes has that forward-backward-forward frame issue, and perhaps the GL-using Chrome 58 bypassed the compositor.  If Unity is the problem, you should see that frame order issue outside Chrome.  If you don't, please ignore, sorry.

capn@: When I disable GPU then aquarium doesn't run for me.

The description in non-composited mode sounds like our buffering or partial swap is wrong.

vmiura@: The M59 Beta package for Linux was missing the SwiftShader libraries ( Issue 719507 ), which should be fixed in the next update. Local builds should work fine when using --disable-gpu. Do you have a //swiftshader/ directory with libraries in it?

ivan@: I'm using the Cinnamon desktop, and I haven't seen the issue outside of Chrome. Are you able to replicate it, or are you observing a different issue?

The NextAction date has arrived: 2017-05-15

(Setting next action to two weeks to last comment and Needs-Feedback). Seems this is addressed in the next M59 package.

The NextAction date has arrived: 2017-05-24

Can anyone confirm it's fixed in M59?

I do not know what is exactly meant by "M59", but I did check and after today's upgrade for me to: Version 59.0.3071.61 (Official Build) beta (64-bit), scrolling is greatly improved. I tested only a few sites but on those sites I was able to see a clear difference for the better.

Thanks for the feedback!  M59 is "milestone" 59, which is same as version number.

What was implied in the comment 28 was that "the next M59 package" (minor update)
would include the fix for this issue.  You originally reported that upgrading
M58 to M59 degraded the scrolling performance significantly, but that was
addressed and the fix should have been included in the latest update.

So you confirmed the fix!

Feel free to reopen if anything is still not what is expected.

> Feel free to reopen if anything is still not what is expected.

I am unsure how to reopen, so I Will try replying. Although the issue was resolved with much improvement, it was still slightly there. What I have discovered by chance today is that I can remove the issue by not having the browser window maximized. If I unmaximize the window and just resize it to fit the full screen, the scroll is very smooth and fast responding. I do not mean full screen mode (F11), I just mean maximized vs non maximized. Does something change to make such a difference when maximixed?

@schenney@chromium.org, I see you added a comment, does this require attention from me, or is that doing something?