This is a regression see 597081.
Try native resolution.
Try #enable-use-zoom-for-dsf to Disabled.

This document contains four 1424 x 1800 CMYK bitmaps, and no other text or graphic components.

Converting PDFium to use Skia instead of its custom blits will result in a performance improvement, but since scrolling will require PDFium to on-the-fly decompress the bitmap images it will require quite a bit of surgery to make it truly performant.

    sed 's/\r/\n/g' < gre_research_validity_data.pdf |  grep -B1 -a /DCTDecode

    for OBJ_NUM in 39 3 9 15; do
        qpdf --show-object=$OBJ_NUM --raw-stream-data \
            gre_research_validity_data.pdf > \
            gre_research_validity_data_$OBJ_NUM.jpg ; 
    done

I believe that  crbug.com/619117  shows the ultimate root cause and fix for this bug. The problem is not that this PDF is too complex, rather the problem is that PDFium times out its rendering pipeline when scrolling, leading to a lack of feedback. This bug should probably be closed as a duplicate of 619117.

I'm reopening this bug.  Bug 619117  covers the poor scrolling performance, but this PDF also demonstrates (as was mentioned above) excessively slow image decoding.

Tracing with the fix to 619117 enabled makes it easy to see when images are decoded. The images on the 2nd and 4th pages each take over 300 ms to decode, inside of chrome_child.dll!CPDF_ImageCacheEntry::ContinueGetCachedBitmap.

The majority of that time is spent in chrome_child.dll!AdobeCMYK_to_sRGB and at least 40% of that is spent in chrome_child.dll!_FXSYS_round - it should be possible to speed up this function, especially for this specific case, by an order of magnitude or more.

The bitmap scaling, in chrome_child.dll!CStretchEngine::ContinueStretchHorz, is done per-frame and does not appear to be a significant problem.

Adding Cary as we're in the process of bringing the Skia port up to speed that should change these numbers I believe.

I'm tidying up a patch that improves the performance of AdobeCMYK_to_sRGB by about 65%, which then improves worst-case scrolling performance on this PDF by about that amount.

"I'm tidying up a patch that improves the performance of AdobeCMYK_to_sRGB by about 65%, which then improves worst-case scrolling performance on this PDF by about that amount."

Woohoo that's great!

FWIW, Skia has something similar:
https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkOpts.h?sq=package:chromium&l=62

This isn't a public API (therefore not usable by pdfium?).  But it makes me think that in the longer term, we may want to think about switching pdfium to use Skia's image decoders.

But I would guess this may require some real effort.

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

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

commit 1530a0e1a9408e3caa17cfdc2cdd77b527eec3a3
Author: thestig <thestig@chromium.org>
Date: Wed Jun 29 14:57:23 2016

Roll PDFium afe3e46..017052a

https://pdfium.googlesource.com/pdfium.git/+log/afe3e46..017052a

BUG= 604587 ,617365
TBR=ochang@chromium.org

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

[modify] https://crrev.com/1530a0e1a9408e3caa17cfdc2cdd77b527eec3a3/DEPS

Another good document to test is to make sure 
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf scrolls nicely on less powerful machines.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Setting PDF bugs assigned to me back to untriaged so they can get re-assigned as needed.