Slowness on mobile devices

[lalith-b]

I saw the original document on the safari browser on my iPad and then I tried to see the html version. its very difficult/glitchy to scroll the document (Not as smooth as the pdf rendering engine in iOS.) Can it be made more smoother with zoom controls on pinch up and pinch down ?

[iapain]

Try loading pages one by one in dom via ajax. It works better.

[coolwanglu]

It's a known issue, optimization for mobile devices will be done later, and, as @iapain said, might be a work of the frontend.

[lalith-b]

This alone can make this project as a standalone super feature. Most of the pdf2html converters dont support mobile devices and most of mobile devices has inbuilt javascript based rendering mechanism which screws up the UI. It is really a nice to have feature if there's mobile support for the html's like a command line arg--

pdf2htmlEx somefile.pdf --ipad
pdf2htmlEx somefile.pdf --iphone3.5inch
pdf2htmlEx somefile.pdf --iphone5

what do you guys think about this ?

[coolwanglu]

Can you elaborate what should be done, for example, especially for iphone5 ?

[iapain]

Pardon me, what these options going to do? Problem is that PDF is usually fixed layout document and text won't re-flow on mobile devices, that is the core problem on small screen devices.

However, I am in a favour of adding support for preset files. e.g. ipad.preset which would contain something like this --zoom 1.33 --space-as-offset 1 --tounicode -1.

[coolwanglu]

Yes, somebody asked me about this before.

I've not found a trivial way to make GetOpt accepting a file as
supplementary parameters.

So maybe I need parse some format myself.

I'll use JSON if I'm writing in Python, but how about C++?

Anyway it'll be a 'user-experience' feature, but not a 'technical'
features, which is far less interesting to me...

Speaking of mobile devices, will it be faster if images are not included,
say --process-nontext 0. Or maybe it will improve loading time only?

On Wed, Oct 3, 2012 at 6:58 PM, Deepak [email protected] wrote:

Pardon me, what these options going to do? Problem is that PDF is usually
fixed layout document and text won't re-flow on mobile devices, that is the
core problem on small screen devices.

However, I am in a favour of adding support for preset files. e.g.
ipad.preset which would contain something like this --zoom 1.33
--space-as-offset 1 --tounicode -1.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-9102427.

[coolwanglu]

Another obstacle is that I've got no smart phones. So no way for me to optimize/test/debug.

[coolwanglu]

@iapain btw, --fit-width might be better for you

[lalith-b]

for presets basically which has ipad/iphone may display html content with no grey space and the page zoomed to the particular size (ipad 1024x768 for landscape and 768x1024 for portrait in viewport setting in meta tag and for iPhone <iPhone 5 will have 320x480 where as iPhone5 will have 640x1136).

for scrolling iscroll js can be used to make it smoother - http://cubiq.org/iscroll

simple tweaks which make this a better for use on all platforms. I hope i'm making clear of the objective and not deviating.

@coolwanglu you can use some online simulations like http://quirktools.com/screenfly/ which will help you to view on simulators, its very close to a real device but its never = to a real device.

[lalith-b]

yeah I tried --fit-width but the issue arised when turning the device to landscape and portrait mode. The grey spaces will show up when turning the devices.

[coolwanglu]

Still not clear withe the viewports.

What do you expect when you rotate your device?

On Wed, Oct 3, 2012 at 7:53 PM, Lalith B [email protected] wrote:

yeah I tried --fit-width but the issue arised when turning the device to
landscape and portrait mode. The grey spaces will show up when turning the
devices.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-9103599.

[lalith-b]

the pages when rotating the device must adjust to fit the screen's new width after rotation.

[coolwanglu]

I see, that sounds like a UI feature to me

On Wed, Oct 3, 2012 at 7:59 PM, Lalith B [email protected] wrote:

the pages when rotating the device must adjust to fit the screen's new
width after rotation.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-9103720.

[iapain]

@coolwanglu IMO single line key-value would be ideal for preset file e.g.

f=1
l=1
output-dir=~/Documents
space-as-offset=1

I can patch this if you want. I still don’t see it as top priority work.

Regarding Mobile devices @coolwanglu problem is not exactly with width and viewports. It's more related to memory optimization in iOS which degrades some features when memory warning is received. There are quite a few tricks to make it more responsive as mentioned here.

http://stackoverflow.com/questions/9941972/slow-list-view-scrolling-on-ipad-when-scrolling-in-an-overflowauto-div

@deathlord87 Based on my tests on iPad. I have found that scrolling is very laggy, rest all works with proper zoom option.

[lalith-b]

yes the scrolling is slow only because of the javascript. Try removing the jquery in manifest and run on iPad. Its better than the app with the jquery. i really dont understand what the javascript does.

About memory warnings. It's beacause of the scrollable div area as I've read. Thats why i suggested iscroll dont know if that will work either, its all about performance.

@iapain also try compiling the sources with loading the html with the following change in manifest.

<!body>
<!div id="pdf-main">

to

<!body id="pdf-main">

It loads a bit better. I will run performance tests with instruments in mac and give some ideas of memory peaks.

[coolwanglu]

the format is ok to me,
maybe need a new argument somehing like --cfg-file , which read
and process as if --cfg-file is replaced by the content in the
file.

There's another concern,
Right now there's a argument --data-dir with which you can provide
customized templates, js files etc.
Maybe --cfg-file is a little bit overlapping with it ? Not sure.

On Wed, Oct 3, 2012 at 8:16 PM, Deepak [email protected] wrote:

@coolwanglu https://github.com/coolwanglu IMO single line key-value
would be ideal for preset file e.g.

f=1
l=1
output-dir=~/Documents
space-as-offset=1

I can patch this if you want. I still don’t see it as top priority work.

Regarding Mobile devices @coolwanglu https://github.com/coolwangluproblem is not exactly with width and viewports. It's more related to
memory optimization in iOS which degrades some features when memory warning
is received. There are quite a few tricks to make it more responsive as
mentioned here.

http://stackoverflow.com/questions/9941972/slow-list-view-scrolling-on-ipad-when-scrolling-in-an-overflowauto-div

@deathlord87 https://github.com/deathlord87 Based on my tests on iPad.
I have found that scrolling is very laggy, rest all works with proper zoom
option.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-9104122.

[coolwanglu]

jquery is for selective rendering(pages outside the screen will be hidden),
handling links (without js you can only arrive at the page of the
destination, instead of the precise box)

I think server support is necessary for the optimization you mentioned.

On Wed, Oct 3, 2012 at 8:43 PM, Lalith B [email protected] wrote:

yes the scrolling is slow only because of the javascript. Try removing the
jquery in manifest and run on iPad. Its better than the with the jquery. i
really dont understand what the javascript does.

About memory warnings. It's beacause of the scrollable div area as I've
read. Thats why i suggested iscroll dont know if that will work either, its
all about performance.

@iapain https://github.com/iapain also try compiling the sources with
loading the html with the following change in manifest.

to

It loads a bit better. I will run performance tests with instruments in
mac and give some ideas of memory peaks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-9104747.

[iapain]

@deathlord87 It would be nice if you can benchmark iOS safari performance with and without hardware acceleration. You can trigger hardware acceleration simply by doing some graphic stuff in css.

[yocontra]

Erics-MacBook-Pro:Desktop contra$ pdf2htmlEX BG_JulyAugust2012-final.pdf --fit-width
pdf2htmlEX: unrecognized option `--fit-width'

[coolwanglu]

@contra which version are you using? If you still see this error after updating to the latest master branch, please file a new issue.

[yocontra]

@coolwanglu - I used the brew formula in the README

[coolwanglu]

That's not the latest version.

On Friday, October 5, 2012, Eric Schoffstall wrote:

@coolwanglu https://github.com/coolwanglu - I used the brew formula in
the README

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-9166010.

[yocontra]

This should work right? http://pastebin.com/raw.php?i=iTnu2m40

[coolwanglu]

Yes.

On Fri, Oct 5, 2012 at 1:41 PM, Eric Schoffstall
[email protected]:

This should work right? http://pastebin.com/raw.php?i=iTnu2m40

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-9166049.

[lalith-b]

Hey everyone, As @iapain as asked i've benchmarked the ios safari and profiled it. The memory peaks as and when we scroll the pages. Safari crashes/freezes when it reaches 14-18MB mark.

When used in UIWebView (Safari View for app development) it crashes at 10+ MB loaded. The memory needs to be handled efficiently so that the scrolling is not laggy. also the page which is visible + 1 back and +1 forward pages alone should be rendered all the other pages need not be rendered. I think too many

elements are the reason for crashing.

Currently when scrolling through the PDF the memory is loaded with the Full PDF and as we scroll the pages on the top is still live in memory, though Its not visible to the user.

I tried with issue65_en.pdf - http://dl.fullcirclemagazine.org/issue65_en.pdf which is loaded as an example. When I reach page 6-10 Its crashing.

[iapain]

@deathlord87 Thanks for your investigation. I think the only way to make work inside Safari is to write your own viewer. pdf2htmlEx does support split output.

Regarding memory leaks, It might be safari bugs. I also tried to optimize and what I out that loading one page one time helps. I am not sure if we should report it to webkit. I need to further investigate about what are the limits and if hardware acceleration helps.

BTW 10+ MB on scrolling is huge, @coolwanglu may it worth exploring flowable text.

[coolwanglu]

@deathlord87 Thanks a lot for your effort! You are right about the memory issue, actually there's similar things done with Javascript, where the invisible pages are hidden, for smoother scrolling on PC.
I'm actually trying to find a way to reduce the number of elements, but 'to not render unnecessary pages' is the job of viewers, and pdf2htmlEX provides only content conversion.
Btw, did you mean PDF or converted HTML?

@iapain issue65_en.pdf itself is 18M, and the size of converted HTML is similar, so 10+ MB did not surprise me.
flowable text is in the TODO list, I will probably start working on it after finishing css/svg.
How much speed gain do you think can be brought by flowable text?

[lalith-b]

@coolwanglu the 18M is the size of the full HTML, its not necessary for the Devices be it mobile/desktop to eat up 18+ MB's of RAM for just viewing 1 page at a time.
And yes! ,you are right the purpose of the project is to enable conversion of content, and 8/10 the conversion happens properly thanks to all your effort. There's much more great things that this project is capable of, I am writing a server side code(Node.js/Shell.js) to enable users to upload pdf's and get converted html as downloads, will open a repo soon.

[iapain]

@coolwanglu Flowable text can dramatically ease Safari rendering problems. On the top of that the result output can fit in any screen which is equally important.

[coolwanglu]

After a quick searching, it does not seem to be as easy as I've thought of, there are many rules related to grammar, space, positions.
So I'll take some time for this after finishing the background staffs.

[iapain]

@coolwanglu @bachboss with --split-page options it's indeed makes it faster on iOS devices.

[bmatto]

My mobile safari rendering issue is more the "tiling" as the render happens. In the browser the render seems fine, and the scrolling is not really an issue in either case.

Can anyone suggest a preferred configuration or solution for the titling that is occurring?

here is an example output file : http://russellreynolds.com/leadershift/issues/FQ2013/html/leadershift-3.html

[ghost]

Bmatto's example above here is really key. Using the base.css included in his example above (see source code of http://russellreynolds.com/leadershift/issues/FQ2013/html/leadershift-3.html) makes all of my pdf2htmlEX's output work flawless on iPads and iOS devices. Probably something were changed in base.css between his output and mine using todays build of pdf2htmlEX.

[coolwanglu]

@josefnorlin Are there any issues with the current version?

[ghost]

Yes, I think so. First I thought it was why this discussion started, but when I found Bmatto's example above, his html output just roared of speed. I did my best to reconstruct what he did. I tried all of the arguments I could, but it didn't change until I ran the base.css code that he used. I haven't figured out what the changes were since he did the output though.

[ghost]

@coolwanglu As I read here you don't have access to smartphones and (or) iOS. I for one would happily donate a small beginning for you to buy an Android/iOS phone/tablet. As much as you've done for us with this project, I think many with me would follow (as that will probably enable even better mobile support for pdf2htmlex). How can we contribute?

[coolwanglu]

@bmatto I guess it'd be better to specify your device and browser.

[coolwanglu]

@josefnorlin Can you provide both versions (fast and slow) of your HTML file? Maybe I will be able to find some clues.

Speaking of mobile devices, currently I've got only an iPad 1, which might be too slow for pdf2htmlEX. For a long time I have not tested pdf2htmlEX's output on modern devices, and I'm not sure if recent ones are fast enough. On the other hand, the lack of devices is not the main reason that I've not been able to fix this issue, there are even performance issues on PC for some PDF files! Although I've been working on it, there doesn't seems to be much progress :( Maybe it's just my lack of knowledge.

I really appreciate your willingness for donation. However I'm afraid that I cannot make any guarantee at this moment, it's not like compatibility issues which are likely to be solved given enough time. On the bright side, as a start I would like to try to optimize the output at least for specific documents on specific devices. Can you please propose some devices (also browsers on them) which match your clients the best? I'll then try to pick the 'easiest' one for me as a start.

[bmatto]

All -

To make the scrolly fun time smooth in mobile safari I used the -webkit-overflow-scrolling: touch; css property on the pageConatiner element. I will say that there was a somewhat odd side affect in that the PDF rendered in a "tiling" fashion. This tiling i'm fairly certain is a direct result of the webkit overflow action - I think they call it a "feature".

I hope this helps.

[coolwanglu]

@bmatto Seems to be an interesting CSS property. Just learned. Thanks!

[ghost]

Thanks @bmatto! That explains a lot. Then the performance issue with iPad Mini which I tried on is solved. And probably for many other mobile devices as well.

@coolwanglu Then I guess there is no fault in base.css. But bmatto's solution would be a cool feature in the project. Great, if you have an iPad 1 already that's probably enough for testing. I'm just so thankful for pdf2htmlEX, so if there is anything you need, please feel free to ask for donations. :) As soon as our website is up I'll let you know as well.

[coolwanglu]

@josefnorlin Great. So I'll include this one and also the 3d transform property in the css file later.

[ghost]

@coolwanglu Awesome!

[Toneti777]

Thanks for the trick..

I don't know if I can help you...
I don't use de pdfhtmlEx.js but if I use "display:none" in the pageContainer element when it isn't on the actual view I'll improve the swipping page performance..

[coolwanglu]

I'll give my ipad to my parents in a month as they need it. Before that I would like to test the 3d transformation rule and the webkit-overflow-scrolling: touch;, and I'll make some quick optimizations.

If any of you would like to provide some sample PDF that might are slow on mobile devices, please post a link here, or I'll just test some random ones from my collection.

[Toneti777]

Here are a complex example..
https://dl.dropboxusercontent.com/u/5581427/lanuevaespana_oviedo_20130909.pdf

I have some problems when try to zoom in an out quickly on ipads..The rendering is slower than android and sometimes safari or chrome suddenly closes.

Let me know when you have the sample for delete the link.

[coolwanglu]

@Toneti777 thanks! I've just downloaded the file, you may remove it now.

[coolwanglu]

I've tested a few tricks mentioned in this thread on Safari / ipad 1G

Test file is demo.pdf as used in pdf2htmlEX demo.,

webkit-overflow-scrolling : scrolling become smoother, but the white background for each page is lost. And it makes Safari crashed a lot.

removing hidden pages out of DOM: I used xxx.innerHTML='', which does not really help

triggering 3d transformation: tried translateZ and translate3d, did not observe any performance boost.

So I did not find any one that seems to be useful. Perhaps it depends on the document.

[b0r1sp]

@coolwanglu While researching on this topic I stumbled across preview.crocodoc.com. I viewed their test-pdf on an iphone 4S and it rendered pretty fast, scrolling and zooming did work smoothly. I wonder if you had a glimpse at their frontend-code?

[coolwanglu]

@typoheads I did read some output for PC browser, but I haven't done that for mobile browsers.
I'm not familiar with mobile web, but I just realized that I could modify user agent.
Will do that soon. Thanks for the reminder.

[b0r1sp]

@coolwanglu just stumbled across the slides-module of google docs: https://docs.google.com/presentation/d/1ZRIQbUKw9Tf077odCh66OrrwRIVNLvI_nhLm2Gi__F0/embed?start=false&loop=false&delayms=3000#slide=id.g30f0fc55_0_56

I poked a bit around and I noticed that they're massively using SVG for at least typo and graphics. I didn't check a slide with photos yet.

[coolwanglu]

@typoheads Indeed.

There is actually an SVG backend in pdf2htmlEX, which is far from mature right now though.

[coolwanglu]

I've created a wiki page summarizing tricks that might help improving the performance on mobile devices:
https://github.com/coolwanglu/pdf2htmlEX/wiki/Mobile-Devices
Thank you very much for reporting them.
Hope it helps, and please feel free to add more if you have found new ones.

It's been nearly 2 years since this issue was created, and mobile technologies have changed a lot. It seems to me that most performance issues happened on iOS devices (am I right?). But I don't think I can confirm it with my iPad 1G, which lag on almost all output of pdf2htmlEX.
A possible reason is due to limitations/defaults of (mobile) Safari, the latest iOS seems to be more open, not sure if it'll help.

Now the issue seems vague to me, some said it's slow, some said it's OK. Some tricks seemed to work for some PDF files, but not for others. If you have certain information for specific types of devices, please also add to that wiki page. For example some kind of files are slow on some kind of devices. Which should help.

SVG might be a solution, or we can just wait until devices become even faster.

[cdelgadob]

@coolwanglu et al. What a post! It's great, and the summary page it's fantastic.

I just miss a short example on how to implement the last two tips:

Hide pages that are out of screen using JavaScript, by completely removing them from the DOM.
Trigger 3d acceleration using translateZ or translate3d CSS property.

Regarding the last one, which I'm experimenting with it right now, I guess that if there are any transform:matrix, it should be converted to transform:matrix3d, to trigger hardware acceleration, right?

[coolwanglu]

@cdelgadob The method of removing pages would be up to the actual UI framework, so I haven't come up with a proper general example.

I think a 3d transform in the outermost container would be enough, but I'm not sure. I guess you need to do some experiments.

[jdbravo]

This problem is still happening, even with new hardware.

I tested with iPad 3 and iPhone 4 and in both the scrolling is very very slow.

Documents generated with --split-pages (lazy load) and without are affected.

If I use -webkit-overflow-scrolling: touch in the #page-container css and documents generated without lazy load, works great. But if I use lazy load and also -webkit-overflow-scrolling: touch Safari and Chrome crash immediately.

I tried to use iScroll too, I don't know if I didn't in the proper way but apparently it's not compatible with the base.css.

If I remove lines bottom:0; and right:0; from #page-container the iScroll allow scroll the document, but it damages the functionality of the pdf2htmlEX viewer.

Any idea how can I speed up the scrolling on iOS with --split-pages ? and why the --split-pages with -webkit-overflow-scrolling: touch crash the browser?

[GeorgeBailey]

I tried it on Chrome on my Samsung Galaxy Note 3, and an old Asus tablet we have, (both are Android devices) and the scrolling is very responsive for me.

I tried this on a few of the pdf2htmlX demo pages, and also the documents from our in-house project.

I think that given enough time, the iPads and iPhones will become more efficient in this area, similar to the Android. (perhaps the latest iPad and iPhone already are)