Presentation layout very slow on mobile

[andrecardoso]

Hi,

I'm trying to use Crocodoc.LAYOUT_PRESENTATION with the slide CSS transitions as is used in the examples. The only thing different that I'm doing is to use hammer.js swipe events to call scrollTo.

It works fine in the desktop but when I run it on mobile (iPad 3 with Safari, Android KitKat with Chrome) the transitions run very slowly which makes a poor user experience. When I disable the CSS transitions, it improves, but it still slow.

Do you have any tips to enhance these transitions?

Thanks.

[lakenen]

@andrecardoso is this slow with all documents for you? Sometimes very complex documents can cause performance issues in viewer.js on mobile devices. I recommend trying a simple document (e.g., text-only, less than 50 pages). If this improves performance for you, then it would be very helpful if you could share the documents with us (api [at] box.com), and we can take a look.

[andrecardoso]

@lakenen simple documents perform better, and I noticed that when the file is still loading and the pages are white it works perfectly. You can notice the slowness using the same document of the remember page example. Here is another document that I've used: http://help.feedingamerica.org/HungerInAmerica/hunger-in-america-2014-summary.pdf

You can see the modified presentation layout example that uses hammer and swipe events here: https://github.com/andrecardoso/viewer.js/commit/da310518b1e395a3f57af291762762b6894d2806

Thanks!

[peetersn]

@lakenen We are trying this as well on mobile devices and the performance is far from production ready (that's what our customer was reporting). I can give some example of the magazines we're trying to render. Our system is hosting the rendered content, so we can't (unfortunately) use any of the streaming features.

airhttps://dl.dropboxusercontent.com/u/2577495/ICE%2069642%20Icelandair%20INFO%20OKT%202014%20final%20ODDI%20LQ.pdf https://dl.dropboxusercontent.com/u/2577495/InTime_Oktoober14_preview.pdf

A few follow-up questions:

1. What are the settings that we can use to improve the speed of the transition? Which is the layout that is the most performant (for magazine types)
2. When the page is not loading, you get a blank screen; which is confusing for the user. Is there anything we can do to indicate that the page is actually loading? What would the API be?
3. Should we wait before we load >50% before actually displaying the viewer?
4. Is it expected that dragging doesn't work on mobile (e.g. iOS) once you've zoomed in?

Thanks a lot!

[lakenen]

@peetersn unfortunately, documents that have many or very large images can cause performance issues on iOS. This is something we're trying to improve, but it's a fundamental issue with how image-heavy documents are converted at the moment.

First of all, please make sure your viewer element is both visible and the correct height. It's possible to get into a weird state when its height is calculated as 0 (which can happen when it's display: none), which causes too many pages to load at once. This is a bug, which you can track here: https://github.com/box/viewer.js/issues/152.

1. If the above does not apply or doesn't seem to help, there's not much to do unfortunately. You could force PNG representations, but that's not ideal (and would require all conversions to enable the non_svg option).
2. You can actually style the page while it's loading to add, for example, a loading indicator (see styling pages).
3. It's unclear what you're asking here. If it's because too many pages are loading, then it's likely because of the above issue I mentioned. The viewer does not function properly unless it is visible (display: block;). If you need to hide the viewer for some reason, I recommend using visibility: hidden;.
4. I recommend using the browser's native zoom on mobile devices. The unfortunate truth is that it's extremely difficult to emulate pinch-to-zoom performantly in JavaScript, so it's better to design your app to allow the full page to zoom if necessary. You can use viewer.js's zooming functionality on mobile, but not in combination with the native browser zoom.

Another thing to take a look at is useWindowAsViewport (see viewer conifig). This option allows the viewer to use the entire browser window as viewport, which feels much more natural on iOS devices, because the browser's native scrolling takes over and effects such as bounce and browser chrome auto-hide (e.g., the navigation bar) work as expected.

I know it's frustrating to have performance issues, but image-heavy documents are very difficult for mobile browsers to handle with graphics and memory constraints. Again, we're working on ways to improve the conversion process so the resulting assets are easier for mobile browsers to handle.

[peetersn]

@lakenen Thanks for the very detailed and very helpful answer to my quite poorly formulated comment. Much appreciated.

I'm discussing with the team and will get back to you. The point that it needs to be visible is an interesting point... We had the idea of putting the viewer to display: none (that was point 3.) until a few percentage of the pages are loaded, but I guess that this is a bad idea. Removing this has already improve the perceived performance. I'll look at the other points in details.

Styling works too, awesome.

[lakenen]

@peetersn good to hear! I've also patched the bug I mentioned (will be in the next release), so you should be able to hide the viewer, though it won't have the full effect you wanted, because the lazy-loader logic tries to be smart and only load pages that are visible or will likely need to be loaded soon. For long documents, pages are also unloaded as necessary to improve performance, so you might notice that if you scroll to the end of a document, then back to the beginning the pages might reload. That is expected behavior.

[peetersn]

I have indeed noticed that "going back" is often causing pages to (have to) reload or even to hang at loading... While typing this, I realize that this is not very well explained and may be hard to reproduce, but it does happen.

When do you expect it be released to NPM? https://www.npmjs.org/package/viewer

Looking forward to test with this new release.

[lakenen]

@peetersn I just published v0.10.3 to github and npm.