Tested the issue on reported version 66.0.3359.22 using Windows 7,10 and Mac 10.13.3 with steps mentioned below and is not reproducible. Attaching screencast for reference.

1. Navigated to https://github.com/SteamDatabase/GameTracking-Dota2/commit/b930575edb9415a94aedde60f6e72efe7295206a#diff-aecd83e5dcc6ae823b84e2c67e555da5 and waited till all diffs loaded.
2. Scrolled down using Mouse wheel from desktops and touchpad in laptops -- observed no lag while scrolling.

@Reporter: Please check the video and let us know if we miss anything? Does this repros on other machines and other OS? Also please check the issue on fresh profile which do not have any apps/extensions and all flags set to default.

Thanks!

Deleted: 821071.mp4 10.6 MB

	821071.mp4 10.6 MB View Download

I'm not sure if your recording is low FPS, but the scrolling is considerably slower than the mouse movement there.

For me, on page load the scrolling smooth, but when I let github load all diffs on the page, the scrolling does become jaggier.

I've attached a screen recording of devtools performance compared to that heavy link and another small diff. The timeline is considerably different.

Deleted: 13-090529038.webm 4.1 MB

	13-090529038.webm 4.1 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce this issue on reported version 66.0.3359.22, on latest canary 67.0.3370.0 using Windows 10, Ubuntu 14.04 and Mac 10.13.3 with steps mentioned in comment#0 and #3. i.e; Seeing High Rendering value in performance tab on scrolling.

This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.

Thanks!

Deleted: 821071 in M66.mp4 1.5 MB

	821071 in M66.mp4 1.5 MB View Download

Deleted: In M-60.PNG 96.5 KB

	In M-60.PNG 96.5 KB View Download

I can see the same rendering time as well for the huge diff page. Ali do you happen to know whether this is normal for such pages?

Attached a trace. The page scrolls buttery smooth on a high-DPI device (or by passing --enable-prefer-compositing-to-lcd-text). Without that, we're forced to scroll on the main thread due to having a position: fixed Element. Interestingly - I don't see anything fixed on the page. Here's the offender: 

<div id="js-pjax-loader-bar" class="pjax-loader-bar">
  <div class="progress"></div>
</div>

Neither the outer nor inner <div> have a non-empty rect (outer is 0x0, inner is 0x2). Animations team had some ideas on not forcing slow scrolling due to fixed Elements. flackr@: surely we could avoid slow-scrolling for unrendered Elements like this, right?

+Paint-team as cc if they want to take a look at the trace - looks like we update compositing on every frame of scrolling which takes a long time (probably expected as this is such a large page). That said, is the compositing step necessary every frame?

Deleted: trace_githubscroll.json.gz 2.8 MB

trace_githubscroll.json.gz 2.8 MB Download

The mergedinto bug is private. May I ask why?

No good reason. I just made it public.

Is it actually a duplicate? As removing "js-pjax-loader-bar" (fixed element) makes scrolling much smoother (it doesn't fix slow update layer trees though).

Yes it is a duplicate, in that the CL I am writing and referred to in the
other bug makes this pages scroll much faster.

Re:12, does your CL just improve main thread scrolling performance or does it cause this case to impl scroll? If the former, I think this is pretty low-hanging fruit to keep us on the fast path. I know flackr@'s team is working on some ideas on how to impl scroll with pos:fixed more often - it would be really simple to only force main thread scrolling if the pos:fixed is visible in some way.

It improves main-thread scrolling performance.

Ok thanks. In that case, I'll undup so this can track the main vs impl issue and flackr@ can have a look when he gets back next week.