P.S. I picked up the sample PDF document randomly from
"filetype:pdf" Google search results and I don't have any
intention for the content of the document.  Any scrollable
PDF document should reproduce the issue.

This is definitely sluggish; the scroll bar seems to race ahead of the rendering.
dsinclair@ can you analyze a trace of it?

It is very slow to bring up print preview that one can choose printer name and change settings. Don't know if it is related.

Should be dupe of https://bugs.chromium.org/p/chromium/issues/detail?id=597081

It might be same, but the symptom looks different than  issue 597081 .
597081 is talking about tiled layer composition is somewhat delayed,
and cause tearing-like effect (screenshot in  issue 596282 ), but
this is just about janky scroll.

On OSX, I haven't witnessed such tearing.

I don't think it's (directly) related to  issue 597081 . I took a look at traces in both Canary (where scrolling is more Janky) and Stable (where it's better) and can't see anything jumping out. I think this needs a bisect. 

Could not differentiate much on Mac 10.11.4(MacBook Air) using canary 51.0.2704.0 and stable 49.0.2623.112.Anyhow on both versions the mimehandler just keeps growing and the   CPU usage too increases.Please find the attached screen shot of chrome Task-manager.
Example PDF : http://www.iso.org/iso/annual_report_2009.pdf
Could you please help for triage it further.

Deleted: Canary_Stable_Task Manager.png 133 KB

	Canary_Stable_Task Manager.png 133 KB View Download

durga.behera@ The problem is more about *CPU usage* rather than memory consumption while scrolling.  It seems the current stable (M49) seems
already switched to material design PDF viewer, so I guess this has happened
since older (Material design PDF viewer was enabled by default at M47?)
version.

Today I checked this on a Windows desktop (Win10, Core i7-6700K) with 52.0.2705.0
canary (64bit), and the scrolling was quite smooth, even though the machine is
relatively powerful. From Chrome's task manager, the mimehandler process and
the GPU process never go beyond 10% CPU while scrolling.

On the other hand, my MBP (Core i5 2.6GHz) the mimehandler process ate 80% CPU,
and the GPU process ate 35% CPU at most while scrolling.
On Pixel (Chrome OS, stable M49) also exposes similar symptom, and easily
saturates CPU while scrolling.

I don't think the CPU/GPU power difference can explain the difference, and my
guess is something is wrong with Mac/ChromeOS scrolling.

Yes even I have observed the same(referring to comment #8) while performing the scrolling the CPU usage was going 30% to 45% and so on, and after stopping the scrolling it reduces to 0% again on both stable and canary.

Can you please suggest any data point to consider good and Bad regarding this if at all anything to further triage it.It looks very hard to bisect based on the scrolling observation though.

What bokan@ said in comment 7 is that there is difference between
stable (M49) and canary (M51 or M52), but I am not sure the difference.
So I'm not sure we can find an exact change that regressed this performance
by bisection either.

My current guess is that this happened when Chrome switched to use material
design PDF viewer, but the MD PDF viewer had been there under chrome://flags
for some time then.  Probably bisection will find the CL that flipped the
flag, which is not so meaningful.

I can't find a flag in chrome://flags to turn on/off MD in the pdf viewer. Also, it looks to me like both M49 (stable) and M51 (canary) are using the same UI so I don't think that's different between the two.

Another interesting finding...in M51 there's an elastic overscroll effect when you scroll past the end/beginning of the document that's absent in M49. The fling velocity seems much higher too. This might indicate we're somehow scrolling on different paths (though I would have expected that to show up in a trace). I'll try to bisect the change today. I suspect it's not the flag since it's on/off in both M49 and M51 but even if there's a difference we could just bisect while keeping the flag on, right?

I did a bisect, the elastic overscroll issue is caused by enabling wheel event gestures and is unrelated to the performance impact. I started bisecting again with wheel gestures disabled (wheel gestures had some regressions in the bisect range that made it impossible to test) and it looked promising but I ran out of time. I'll try again on Monday.

See  issue 596778  for elastic overscroll. It was explicitly allowed for MacOSX because that is the way it functions in safari as well. 

Yup, I think it's fine. I just thought the two might be related but it turns out not to be the case.

re comment#13, IIUC MD PDF viewer was launched in M47, so I think the chrome://flags to switch on/off the viewer existed M46 and before.

as per comment #12&14,assigning to @bokan as he already started working on bisect.

Thanks,

I think I've narrowed it down to what the cause of (at least my) perceived sluggishnes.

I don't think this is an issue with the plugin but I seem to be able to get into a mode where touchpad scrolling is much faster than normal. Flinging in this mode causes the page/scrollbar to race up while the plugin can't keep up which results in a feeling that the plugin is "sluggish" but I think the real issue is the scroll speed.

This seems to be related to wheel gestures. I'm unable to get into this state using --disable-wheel-gestures. It's a little strange but the only way I've found that I can get into this mode is by starting Chrome with the PDF file as the argument on the command line. The PDF then loads almost instantly (rather than 4-5 seconds loading when navigated to...not sure why that is). The issue seems to be rather intermittent for me, sometimes reproducing consistently, other times quite difficult to reproduce.

Over to dtapuska@ since it seems related to wheel gestures. Let me know if you need help reproducing it.

Hmm; PDFs are doubling their scrolling values.

See  issue 604734 

Marking as fixed with change:

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

commit 874feac6c0e08aab52bd08fe33d5daee0ae07fa5
Author: dtapuska <dtapuska@chromium.org>
Date: Wed Apr 20 16:08:05 2016

PDF scrolling with wheel gestures

Scroll gestures may be generated twice, as a plugin
may 'resend' them if not fully consumed by the plugin,
and they may be generated once again inside the main
renderer host. Re-sending of gesture scroll events from
the plugin causes double scroll values in PDFs
This was more noticable on Windows which uses a larger tick counter (120) vs
53 on Linux.

Fix is to not generate gestures inside the plugin container.

BUG=  604734  

Review URL: https://codereview.chromium.org/1898333002

Cr-Commit-Position: refs/heads/master@{#388508}

[modify] https://crrev.com/874feac6c0e08aab52bd08fe33d5daee0ae07fa5/content/browser/renderer_host/input/mouse_wheel_event_queue.cc

Thanks for narrowing down the issue, David and Dave!