This behavior appears in Version 51.0.2704.84 m as well as Version 53.0.2764.0 canary (64-bit).

The behavior also appears with https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf

This behavior happens whether enable-use-zoom-for-dsf is enabled or disabled.

This is most likely a PDF plugin bug, not an issue in Chrome itself. Chrome's compositor tries to ensure that the plugin contents are updated at a reasonable rate, and looking at traces it doesn't seem like there's any GPU backpressure that could be causing the plugin to slow down rendering.

I wonder if it's hitting kMaxProgressivePaintTimeMs and giving up on painting just before it tries to scroll again, thus invalidating the old work.

I'm afraid that your guess is totally wrong. The problematic constant is not kMaxProgressivePaintTimeMs, it's kMaxInitialProgressivePaintTimeMs :-). If I change that from 10 to 300 then the problem goes away and repainting happens consistently in a timely manner.

Presumably a proper fix would involve changing both constants, or changing how they are used.

Aborting a paint operation partway through only makes sense in very rare scenarios. With kMaxInitialProgressivePaintTimeMs set to 10 this means that if fast scrolling takes longer than ~10 ms then it will take infinity ms.

Mouse move messages are particularly problematic because they come in at such a high rate, and because the OS (Windows for sure anyway, presumably others) can seamlessly discard old mouse moves if the application takes a bit longer to process them.

The same issue can happen with keyboard scrolling - by holding down the up or down arrow keys on a complex page it is easy to get into a state where the scrollbar updates but the pages does not. This is not good.

Thanks John.

Issue 617365 has been merged into this issue.

brucedawson@ I assigned this to you as I believe you have a potential patch to solve the fps issue?

Yep, I'll take it.

My current patch is just to increase the timeouts. This works very well but I'll have to make sure I fully understand the purpose of the timeouts before committing a fix.

See also  crbug.com/318175  whose main root cause is the same as this one (keeping it open to investigate other issues it reveals).

 Issue 439283  has been merged into this issue.

Consolidating all of the test PDFs that I've seen in various bugs:

 crbug.com/318175  - http://www.valvesoftware.com/publications/2011/ValveXperf-Dawson.pdf
 crbug.com/318175  - http://media.steampowered.com/store/steammachines/SteamMachinesBroc_WEB.PDF
crbug.com/582752 - https://upload.wikimedia.org/wikipedia/commons/f/fd/West_Bank_Access_Restrictions.pdf
 crbug.com/523915  - https://people.apache.org/~xli/presentations/history_Intel_CPU.pdf
crbug.com/617365 - https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf
 crbug.com/619117  - http://www.suncadiaresort.com/assets/pdfs/June%202016_Activity%20Guide_web.pdf
 crbug.com/439283  - http://www2.futureware.at/novena/01docmap.pdf

Note that the slowdown in https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf is partially due to inefficient image decoding which can be easily improved.

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

commit 60e37416d6640d90cc6942b361d36cb77531174f
Author: brucedawson <brucedawson@chromium.org>
Date: Thu Jun 23 18:39:21 2016

Increase PDF display timeouts

On moderately to very complex PDFs it can take more than 10 ms to
render the page, especially when scrolling. This means that rendering
hits the kMaxInitialProgressivePaintTimeMs timeout and is terminated
without any pixels going to the screen. This means that (other than
scrollbar movement) the user gets *zero* visual feedback until the
mouse/mouse-wheel/key-presses slow down enough to get a fast-frame
in.

This change increases the timeouts. Any PDFs that can render their
scrolled image in less than the timeout will now be continuously
updated.

Because the painting is in a separate process from the renderer
and scrollbars there is little downside to increasing the timeout.
The only downside is a slight increase in the latency of rendering
the final frame when the user stops scrolling a complex PDF.

For complex/expensive PDFs the typical increase in latency will
be half of the floor of the PDF render time and the timeout,
so about 125 ms for complex/expensive PDFs.

For trivial PDFs the increased timeout will make no difference.

On the test pages from the four attached bugs the improvement is
dramatic. Scrolling is sometimes slow, but frames continue being
delivered without the user having to pause and wait for Chrome to
catch up.

Improving the performance of decoding and scaling images, or doing
the decoding and/or scaling asynchronously while still displaying
scrolling PDF imagery, is left for a future bug. This fix is
necessary for future improvements but does not make other
improvements unnecessary.

BUG= 318175 ,582752,617365, 619117 

Review-Url: https://codereview.chromium.org/2057143003
Cr-Commit-Position: refs/heads/master@{#401660}

[modify] https://crrev.com/60e37416d6640d90cc6942b361d36cb77531174f/pdf/pdfium/pdfium_engine.cc

Long-term fix to scrolling is to resolve  bug 439283 , but this particular issue is now fixed.