Scrolling extremely slow with Bluetooth spec PDF (core_v4.1.pdf) (chrome extension)

[agoode]

Scrolling is extremely slow with Bluetooth spec PDF (core_v4.1.pdf). When looking at the task manager, I see a lot of CPU usage for a while after I am done scrolling. I don't see very much that is helpful in the Chrome profiler, just that "(program)" is taking up 84.83% of time.

PDF available here: https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=282159
(from https://www.bluetooth.org/en-us/specification/adopted-specifications)

I am using the Chrome extension, version 1.0.604.
Here is my Chrome info:
Google Chrome 38.0.2114.2 (Official Build 287444) dev
Platform 6127.0.0 (Official Build) dev-channel daisy
Blink 537.36 (@179495)
JavaScript V8 3.28.54

Thanks.

[CodingFabian]

sweet, 20MB 2700 pages mostly text. Will do a bit of profiling. Right now I assume that this document just contains way to much text layer elements. A few improvements regarding the text layer have landed recently, and at least one is pending. so this will hopefully get better.

[CodingFabian]

i think #5178 would help a lot. I am seeing 30% forced relayouting caused by the scroll handler. Maybe Ill spend some time today on the scrolling issue.

[CodingFabian]

we have landed a fix trying to gently improve the scrolling. can you check with the latest online viewer:
http://mozilla.github.io/pdf.js/web/viewer.html
and let us know how much it has improved?
Thanks!

[agoode]

Doesn't seemed to have made a difference, at least not with that document on my ARM Chromebook.

[CodingFabian]

Thanks for the feedback.Is that the 1.7GHz CPU? I would assume that this contributes to the fact that it scrolls laggy for you. we should really see if we can lighten the load for layouting when text layer is present.

[agoode]

Yes, this one: http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook

It's getting close to 2 years old now.

[CodingFabian]

according to @nnethercote #5209 improved scrolling performance for him on a different document.
Because the bluetooth spec scrolls acceptable for me now, its hard for me to judge impact of these changes. So i would appreciate feedback :-)

[agoode]

It might be slightly better, but not much. I am looking into the profiler and timeline a bit, there is a lot of time spent in the request animation frame stuff. Even when idle, the page takes ~30% of CPU. This is caused by repainting something every frame, triggered by some sort of update. I have to look more deeply.

Finding the source of the spurious repaints is probably the solution.

[CodingFabian]

yes its the scrolling that causes many reflows/repaints. combined with the text and annotation layer which contain too much elements. one of my changes moved that code to rAF to at least reduce the frequency of it being invoked and also run it in a slot where it does interfere less with rendering.

[timvandermeij]

Closing as fixed by many recent optimizations and #5569. It's quite fast for me now.