Handle large (1000+ page) documents better

[lakenen]

Currently, we generate the DOM objects for all pages at init, but we could be smarter about loading only a small subset of these pages, then adding more (and removing some) as necessary.

[priyajeet]

Not sure how you create and insert the dom into view right now. But if its not done in bulk, do that instead so that there are only a few repaints.

[priyajeet]

Maybe start using the shadow dom on browsers that support it!

[FredKSchott]

We're seeing this issue on mobile, where the entire (sometimes huge) document is loading on initialization even if they only want to see the first few pages. The resulting load is killing our users.

[lakenen]

Viewer.js should never load more than ~16 pages at once unless they are somehow visible. Could be a bug, though... are you sure this is the case?

[FredKSchott]

I'm seeing it load an entire 23-page document. I can test with a larger one later today. On version 0.10.1, fwiw

[lakenen]

Could be that the check for mobile is broken on whatever device/os you're using... What do you see when you log Crocodoc.getUtility('browser').mobile? On non-mobile (and IE >= 10) we load more pages at once.

[FredKSchott]

Ah, I ran that test on a desktop browser :) But emulating a mobile browser (/w User-Agent), I'm still seeing it load entire documents on first load

[FredKSchott]

Regardless, 16 is a little higher than we'd like for our project. Can we make this default configurable?

[lakenen]

Yep, that's certainly possible! Unfortunately, this option controls both how many pages to load at once and how many pages are "loaded" at once. On mobile devices we also unload pages that go outside of this range to prevent memory issues. The only problem with this is that you'll probably see pages that were once loaded showing a spinner again briefly while they're being re-inserted into the DOM.