pdfjs zoomed vectors slow on Firefox

[johnwillyn]

This may be more of a Firefox issue that PDF.js, but when I zoom a PDF from a drawing to 270%, the rendering speed slows dramatically. Chrome does not exhibit this problem. It can take up to 30 seconds to display the vectors and profile shows most of the time is in the Canvas stroke method. I am happy to upload the PDF if it would help.

[timvandermeij]

@johnwillyn Yes, an example PDF would help a lot.

[johnwillyn]

Here you go (in my Dropbox public folder).

https://dl.dropboxusercontent.com/u/23831081/Lynch-A3%2C4%2C5-pln_2014_05_02.pdf

It is a very common case of a drawing floor plan (generated by AutoCAD). I am trying to narrow this down and will report anything else I find.

I am a fan of pdfjs and I have only been exploring for a couple of days. Seems like very clean structure and code, and I am already tracing into the canvas code that maps pdf ops...hope to give back and contribute at some point.

[timvandermeij]

@johnwillyn Good to hear. I have opened this PDF with the most recent PDF.js version and I cannot reproduce the problem (using Windows 7 x64, Firefox Nightly 34.0a1 64 bit and the latest PDF.js development version). I can zoom to 500% and more and it still renders instantly (in less than a second) for me.

Perhaps you are using an older version of PDF.js. Could you try opening the file with https://mozilla.github.io/pdf.js/web/viewer.html (the latest version of PDF.js) using the Open File button in the toolbar and see if that resolves the rendering issues? We have landed a lot of performance patches lately.

It if does not resolve the issue, please also post some configuration details (OS name and version, browser name and version and PDF.js version used) so we can look into this.

[timvandermeij]

Note that you can find your PDF.js version by opening a PDF file and checking the console. It should display something like this:

PDF de67eb5655ece845946529a4a9339f4 [1.5 Microsoft Word 2013 / Microsoft Word 2013] (PDF.js: 1.0.509)

[johnwillyn]

Hi Tim, it appears to be specific to Firefox; Chrome and Safari both render in split second time.

I am running Firefox 31, I believe I have the latest pdfjs (did a new clone last night), but it does not show up in the console:

PDF 5fd93986eff2f6d745640b61afc961f [1.3 Mac OS X 10.9.4 Quartz PDFContext / AutoCAD 2013](PDF.js: -)

MacOS v10.9.4

I am trying to figure out why the version does not display in my console properly. Chrome shows the same, but renders lightning fast.

[timvandermeij]

You can also install the development add-on (I use that too) to always use that latest PDF.js version. You can install it by clicking here: http://mozilla.github.io/pdf.js/extensions/firefox/pdf.js.xpi

[johnwillyn]

Will give that a try. I did a fresh build of generic and run from that directory, and now I get this for version:

"PDF 5fd93986eff2f6d745640b61afc961f [1.3 Mac OS X 10.9.4 Quartz PDFContext / AutoCAD 2013](PDF.js: 1.0.509)"

Still rendering very slowly on Firefox 31.

[johnwillyn]

OK, installed the add-on; still no difference on Firefox.

I am hopeful of tracking this down because it exhibits the same slow performance on iOS Safari, and stops rendering above 130%. Perhaps these issues are related in some way (clipping mostly offscreen vectors, etc.).

[johnwillyn]

BTW, you may perceive that it is finished rendering in a split second on Firefox, but because it appears to be doing double buffering (with some sort of CSS transform), it is actually still rendering in the background. Look in the 'middle' of the document (not the screen) and you will see the rotating 'pinwheel' as shown in this screen shot (it is always displayed at the center of the document rather than the current zoom view).

[timvandermeij]

The loader also disappears within a second for me, so it's really done with its rendering.

[johnwillyn]

Damn, this is crazy. I have it now on my desktop and laptop, and other than some differences in double buffering, I am seeing basically the same performance (both on MacOS 9.x). I am also hooked into the debugger on my iPad through Safari, and while it stops displaying at 130% zoom, the calls in the Canvas graphics module continue to execute (and stop at my break points).

I am an graphics guy from way back (helped develop AutoCAD 'back in the day') so I will dig into this and report back what I find.

Thanks for your responsiveness and willingness to try and reproduce.

[timvandermeij]

You're very welcome, and I'm curious to see what you find.

[johnwillyn]

I have a little prototype that renders a subset of these vectors in JSON format in a Canvas on top of a map and it does all the clipping to the viewport before drawing. It is very fast, and pans in real time, so I will start exploring the differences.

Thanks again

[johnwillyn]

I spent several days hacking this problem, and even hacked in my own vector clipping code to see if that would affect performance. I have not really found the underlying cause of slow performance on Firefox, but it is notably faster on Chrome and Safari, with Safari winning the overall speed test.

I am using the dev version here (since I have hacked it), but here are some videos that show the performance difference I am seeing between various browsers.

If you can think of anything else I should try, please let me know. For now, I have to assume it comes down to the speed of the Javascript and canvas engines in the various browsers:

(Check out the difference of how long it takes to draw the final black vectors in the final zoom frame):

https://dl.dropboxusercontent.com/u/23831081/pdfjs_dev_vector_test_safari.m4v

https://dl.dropboxusercontent.com/u/23831081/pdfjs_dev_vector_test_firefox.m4v

https://dl.dropboxusercontent.com/u/23831081/pdfjs_dev_vector_test_chrome.m4v

[yurydelendik]

@johnwillyn (I assume you are using Max OSX) Could you try "skia" backend, see https://bugzilla.mozilla.org/show_bug.cgi?id=1026009?

[johnwillyn]

I just figured out how to configure the skia backend, and it makes FF now one of the fastest browsers (provided that the console is not open). Thanks. Mystery solved.

I will continue experimenting within the vector drawing code to see if I can optimize some additional items.

[timvandermeij]

@johnwillyn Good to hear! I'll close this issue for now, but any PRs for optimizations are welcome of course. Thanks.