Opened this in Adobe Reader and in Evince, it's painfully slow in all cases the first time you scroll through the document.

What our plugin is noticeably worst at is scrolling within a page that has already been seen before. It feels like we render only what is on the screen, while the other viewers render the whole page into memory and just blit the visible rect into the screen.

 Issue 233881  has been merged into this issue.

I cannot seem to scroll on default chrome pdf view with either my touchpad or touchscreen gesture. I have to use the scrollbar on the side of the screen. This is annoying.

Using a 2017 Microsoft Surface Pro and Type Cover.
I have not tried an another device nor with an actual mouse having a scroll wheel.

re: comment 3 - Is your issue with the same PDF as the original bug reporter, or with any PDF? You may want to file your own bug, rather than commenting on someone else's bug that may not be fully related to yours.

hnakashima@ Regarding the original bug, scrolling 2018BikeComfortMap-min.pdf on Safari is smooth, it is not slow at all. Any chance this can be triaged again?

re: comment 4 - The issue is related to any PDF that I try open. Thanks for the advice. I figuered it would be close enough to the this issue to respond.

Regarding #5:

Safari is still slow to draw, but in contrast with the Chrome PDF Viewer scrolling is not stopped by that, i.e. 
Safari scrolls smoothly to a blank canvas and the contents appear when they are ready.

We need to revisit scrolling so it can be improved further.

There is also room to improve the performance of the rendering itself.

re: comment 6 - Please file a separate bug. Your issue seems to be with every PDF, while the bug reporter's issue is for a specific PDF.

This specific PDF is 6 MB PDF. I think that'll take a while to render no matter what. There's another bug for big PDFs and slow rendering, so I'll add this to my plate.

> in contrast with the Chrome PDF Viewer scrolling is not stopped by that, i.e., Safari scrolls smoothly to a blank canvas and the contents appear when they are ready.

Yes this is exactly what makes this a functional bug as opposed to a performance bug. Viewing dense PDFs in other viewers is just slow whereas viewing the same PDFs on Chromebooks it´s simply NOT POSSIBLE at all. I just had to stop using my Chromebook and fetch a different computer. On that other computer viewing dense PDFs was just as unusable in Chrome but there I could use alternative viewers.

To make things worse the target page number is hidden most of the time, it shows only after some sequence of clicking and/or hovering which I didn't spend time figuring out.

Reproduced on ChromeOS Version 70.0.3538.76 and Chrome 70.0.3558.77 on a Mac. 

One sample, dense PDF that is slow but usable - except in Chrome:
https://yakima-instructions.s3.amazonaws.com/1035059C_FullBack_INST.pdf
(Sample installation manual (with vector graphics) from https://www.yakima.com/fullback )

> re: comment 6 - Please file a separate bug.

BTW some bug scrubbing wouldn't hurt:
  https://bugs.chromium.org/p/chromium/issues/list?can=2&q=slow%20pdf%20scrolling

Reproduced with Chrome OS Version 71.0.3578.27 (Official Build) beta