Tested on windows 7 using chrome latest canary M58 #58.0.3006.0 and latest firefox .. didn't find any difference while scrolling .

Attached screencast for reference.

@blademight-- Could you please check if any flags are enabled and also try with a fresh chrome profile without any extensions and write us back with  your observations , also help us by providing the screencast of the issue if it still exists.

Thanks!

Deleted: 686596.mp4 14.5 MB

	686596.mp4 14.5 MB View Download

@hdodda I forget to say about using full screen, your screencast not using full screen and only 10 pages listed, also I sure you have a better than my CPU 2x2.5GHz, but for me issue is only for chromium-based browser, after ~14-20 page it becomes slow, fps significally drops when scrolling and scrolling becomes not smooth, but in Firefox(Nightly 54) even 50+ pages does nothing to fps and scrolling still very smooth. I created screencast with fresh install of Chrome Canary(I could not attach it here due to 10MB limit):
http://sendvid.com/pgo88tig
As you can see in for me scrolling in Chrome not so smooth as in your screencast :( 
I also found that enabling these flags: 
#enable-v8-future
#enable-experimental-canvas-features
#enable-javascript-harmony
gives good speed-up but it will anyway become slow after 10~20 pages.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

hdodda@chromium.org so did you see my screencast?

Unable to reproduce the issue on windows-7, Windows-10, Mac-10.12.2 and Linux Ubuntu-14.04 using chrome stable version 56.0.2924.87 and latest canary 58.0.3017.0 with the steps mentioned in comment#0.

Reporter@ could you please upgrade the chrome to latest version and let us know your observations if the issue still persists.

Thanks..

@sureshkumari-- Recently i upgraded to 4x2.5Ghz CPU, and it is slightly better, but now after ~20 page it becomes slow, i think Chrome's scrolling uses a way much CPU(smooth even more) than other browser's scrolling...
Also in task manager i see that processes [chrome.exe] in sum cant use more that 25% of cpu, but for Firefox procecesses with e10s enabled it can go up to 60%! Does that mean that e10s can handle CPU cores better than Chrome can?

Testing was on latest Chrome stable version 56.0.2924.87, canary version 58.0.3018.0 and Nightly 54.0a1 (2017-02-19).

I managed to make [chrome.exe] use too up to 60% but even so everything is lagging when i scroll... If i continue scrolling some time, and then stop it will still scroll ~1-2 secs, it looks like it is busy when i scroll, does that means that scrolling pages with a lot content is *busy work* for chrome? Because on firefox it is not.

Thank you for providing more feedback. Adding requester "sureshkumari@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Unable to reproduce the issue on Windows 7 (CPU-3.4GHz), Mac 10.12.3 & ubuntu 14.04 using reported version-58.0.2996.0,stable-56.0.2924.87 & Canary-58.0.3026.0 as per the above recent comments & find the below observation:
1.In full screen mode pages scrolled smoothly & it took just 1ms time to load the pages after 20
2.Same bahaviour observed on firefox browser also.
3.Tested other URl which has more pages & no issue observed.

Please find the attached screencast for reference & it would be better if you provide us the screencast for the same.
Note: As we can't attach a file more than 10MB , we are unable to show you all the pages scrolling in chrome.
Thanks in advance.

Deleted: 686596-Win.mp4 13.9 MB

	686596-Win.mp4 13.9 MB View Download

@jmukthavaram Okay I done another screencast:
http://screencast-o-matic.com/watch/cben6T6TFi
As you can see in chrome after ~17 page and extremly after ~23 its scrolling lags (looks like skipping some pixels), but in firefox no such issues even after ~40 pages.

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

Could some one from Blink>Scroll team, please have a look into this issue.

Thanks.

Requesting the Blink>Scroll team to look into this issue and update the thread.

Thank You...

David, I myself tested this on Mac and couldn't see the lag on Chrome stable after even ~40 pages. Do you have any guess here?

nzolghadr@chromium.org Didn't you see my screencast? (http://screencast-o-matic.com/watch/cben6T6TFi) It clearly shows how it is for me. 
By the way what are your PC specs?(my are on top)

blademight@, it might be helpful if you attach a performance trace. The instructions for how to do that are here: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

You probably won't be able to record for the whole duration so I'd recommend following your steps until things get really slow, then starting the trace, then doing a few scrolls.

Actually, never mind, I managed to reproduce on my Linux laptop - I'm seeing wheel latency well over a second. I've attached a trace -- looking into it now.

Deleted: trace_anime.json.gz 6.3 MB

trace_anime.json.gz 6.3 MB Download

+tdresser@: it looks like we have a saturated main thread but we're dumping wheel events at a very high rate and they're getting backed up for longer and longer. Don't we have some kind of throttling mechanism in the queue? Is it failing in this case?

+dtapuska@, any thoughts on why this would be happening?

Why don't make rendering and scrolling on separate threads?

Re #22, we're repainting the page every frame because of the position:fixed background. I'm not quite sure why this is triggering repaint, I thought it was only background-attachment:fixed that did. This means that we block scrolling on the main thread.

If you delete the background, this should scroll much more smoothly.

Or you can give the background one of the many properties that forces compositing like backface-visibility: hidden or will-change: transform or translateZ(0).

Re #23, we don't automatically promote fixed position yet (issue 626200) due to a scroll position inconsistency bug when you have mixed composited and non composited viewport constrained elements ( issue 663291 ).

sahel@

The GSB/GSU/GSE sequences are queuing up and should get coalesced. I believe the mouse wheel event queue is not setting the synthetic bit anymore which causing this coalescing to occur in the gesture event queue. I'm trying to remember how all this code works...

Nope I checked I don't think this is a regression the synthetic bits were only set on MacOS when we have phase information. So this is kind of expected.

I believe though it would be improved with wheel latching because the GSUs would collapse together.

I thought we coalesced across GSB/GSE pairs. We definitely should.

You can't coalesce across GSB/GSE pairs if you want to maintain the current hit testing approach. I think the right solution here is to block this on shipping scroll latching and then re-evaluate it after it has shipped.

But the site is spinning a loop around and painting on every frame so it isn't a good site in general.

+dtapuska@ About "isn't a good site in general." then why other browsers handles it? Maybe they [can] handle even *isn't good sites* too, so I think chromium should be able to do so as well too.

 Issue 700732  has been merged into this issue.

Re #29: We know it's a problem with Chrome and it's being worked on.

possibly another example but I'm not sure, go https://greenbeanery.ca/ in Edge vs Chrome and the scrolling, both touchscreen and mousewheel is much faster and more responsive in Edge
 

Re #31: Ok, looking forward to it.

Can we have the latest update on this issue? Tagging with M60.

This is blocked on issue 526463 which is actively being worked on.

Both wheel scroll latching and async wheel events are enabled by default in M65. With wheel scrolll latching we coalesce GSU events since they are not wrapped with GSB/GSE pairs, and with async wheel events we only wait for the main thread to handle the first wheel event of the sequence and if it is not prevented by default for the rest of the wheel events in a scroll sequence we scroll without waiting for the main thread to handle wheel events.