How fast is PDF.js?

https://hacks.mozilla.org/2014/05/how-fast-is-pdf-js/

by rnyman • 12 years ago

235 144 12 years ago

hacks.mozilla.org

angersock3• 12 years ago

Minor performance tip: you can disable the creation of DOM elements backing text and whatnot in PDF.js; this allows for faster rendering on some browsers.

You lose easy search, but it can make your life a lot easier if you don't need them.

windsurfer• 12 years ago

You also lose text select (and thus copy+paste)

enlashok• 12 years ago

But you can approximately restore that if you use Project Naptha as well... urgh... please nobody do this.

sp332• 12 years ago

Is it easy to do that?

angersock3• 12 years ago

Memory suggests yes (I think it's just a render param you pass in or something?) but I'll need to check old code tonight to give you a definitive answer.

async56• 12 years ago

Yes, you can build you own personalized extension for Firefox, Chrome or Opera from PDF.js source code, which will disable text layer. (see also #textLayer=off feature at https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js#url-...)

bthorben6• 12 years ago

We realize that the text layer is sometimes a performance problem. We pushed already a lot of improvements to it and there is more too come.

angersock3• 12 years ago

Not your all's fault...the nature of the beast is that a PDF, in the pathological case, could result in thousands and thousands of individually-styled DOM elements per page, right?

Not much to be done in that case.

xenophonf• 12 years ago

"Also security is virtually no issue: using PDF.js is as secure as opening any other website."

I can't even begin to express how much this sentiment troubles me.

Edited to add: A big part of my concern regarding PDFs these days has to do with embedded malware, but in general I'm wary of active content. I'm all for faster rendering, but I wonder how well PDF.js protects against malicious content. I don't use the native PDF reader for that very reason.

lebek• 12 years ago

Why? The point he's making is that not having to install a third-party browser plugin to view a PDF is a big win for security.

Edit in reply to your edit: embedded malware is tailored to exploit a bug in a specific viewer implementation... so I doubt there's much floating around that targets PDF.js, I imagine Adobe Reader is a juicer target. In any case, JS running in the browser is usually well isolated (e.g. no filesystem access), can wreak havoc in the tab but not much else.

billiam• 12 years ago

The wins on confining the content to the browser sandbox as well as integrating .pdf viewing into the browser experience greatly outweigh the current limitations for large file sizes. I hope ongoing work will fix the latter. Pdf.js is an awesome improvement that makes me breathe easier every time I click on a pdf link.

daeken• 12 years ago

I'm all for faster rendering, but I wonder how well PDF.js protects against malicious content.

It doesn't need to; that's what the browser is for. PDF.js doesn't need to -- in any way -- concern itself with security; that's pretty unquestionably a good thing.

singlow• 12 years ago

By not having a plugin, all of the rendering done by PDF.js is contained within the sandbox normally provided for any page.

If a PDF is designed to exploit PDF.js, the worst it can do is the equivalent of a cross-site scripting attack on the page hosting PDF.js.

This is a huge win over the possibility of exploiting a bug in a plugin which runs outside of the browser sandbox.

azakai4• 12 years ago

The point he is making is that PDF.js is just a combination of JavaScript, DOM and Canvas rendering. It does nothing more than a website can do, and running websites is already something that needs to be secure. So this means that all the existing security measures already present in browsers make PDF.js safe to run.

sdfjkl• 12 years ago

Fast enough, most of the time.

_delirium• 12 years ago

I find it fast enough for reading, but not fast enough for skimming or navigation. If I want to page through a book quickly to find something, it just lags way too much rendering the pages; I have to stop every 5 or 10 pages and wait for it to fill them in, or I'll be paging through nothing but whitespace. But it's fine except for that.

bthorben6• 12 years ago

Keep in mind that PDF.js is an engine + a viewer. Just a fast engine does not make a nice experience. There are many things in the viewer that one can do to make the experience of using it feel a lot faster.

pjmlp4• 12 years ago

So slow and CPU hog even on i7 systems, that I always configure my Firefox installations to save PDFs instead.

X45• 12 years ago

Honestly? I only have 2x1.3GHz, but it loads damn fast for files <= 5MB. How large are the files that you open that make your browser inresponsive?

pjmlp4• 12 years ago

Most of the ones that have more than 10 pages, specially CS papers.

acqq15• 12 years ago

Ditto. It's too slow for almost every PDF I want to open. It's too slow for: docs with a lot of pictures, docs with a lot of vector graphics and docs with enough pages.

Thea architects I know have much bigger problems than me. For them it's: every document is way too slow. They would really like if they can put in their html pages the preference "any reader of linked PDF would prefer native code renderer, the content is guaranteed too demanding for js one." They can change the setting in their own browser but their potential clients will just lose the patience.

The other effect is that not only it's too slow, the vector graphics often looks wrong.

darkstalker• 12 years ago

For me it's faster than the 32 bit Acrobat Reader plugin that hung the entire browser for 1-2 seconds every time I wanted to open a PDF with it.

vanderZwan3• 12 years ago

You see a histogram of the time it took to process all the pages in the PDFs in relation to the average time it takes to process the average page of the Tracemonkey Paper (the default PDF you see when opening PDF.js

While interesting data for sure, that's not really answering the same question as the headline there. How about a comparison to the rendering speed of MuPDF?

kevingadd2• 12 years ago

MuPDF doesn't solve the same problem, so it doesn't really matter whether MuPDF is faster.

renata• 12 years ago

MuPDF solves a bit of the same problem, in that it renders PDF while trying to ignore all the extensibility cruft that makes Adobe's PDF reader incredibly insecure.

vanderZwan3• 12 years ago

Maybe you know that there is no default PDF viewer in the Opera Browser, something we would like to change. But how to include one? Buy it from Adobe or Foxit?

If that is the problem being addressed, then I think it does?

One can ask if patching MuPDF vulnerabilities is a bigger hassle than getting PDF.js performant.

X45• 12 years ago

PDF.js is really nice and awesome, but for me it doesn't work for documents with a file size of 11MB. It was a catalogue and to finally get the thing to render faster I used pdf2htmlEX (html5) which slimmed the 11MB file down to about 2MB with no visible quality loss and text would still be perfectly selectable, even in old and crappy browsers like IE7. I'm happily using both on a customers site. The 11MB file rendered good enough on my Client's new PC, but they have an i7 ;) My own box is really slow :/ (saving for a macbook pro)

Currently I was about to write a service to autoconvert PDF documents uploaded via ownCloud into the said HTML5 document, but it seems that even though I've ssh, this server is managed and doesn't come with make and also has no poppler or fontforge libraries available. Meh :(

I'm thinking about compiling the binary with --prefix=~/.local/lib and copy the dependencies I've found to that directory on the server. Hope that works, otherwise I'll need to write an API for pdf2htmlEX on a server where I've root and upload modified & new pdf files to it, then wait for it to finish the html5 conversion and download the files to the right directory using curl. That'd be much more work than just dropping the binary onto the server and executing the service as cronjob for modfied or new files.

Any ideas on howto solve this cleverly?

FooBarWidget• 12 years ago

You should probably report this. Most of the test cases that they used where PDF.js is too slow, involves files so large that even Adobe Reader can't render quickly, or files that are heavily damaged.

X45• 12 years ago

I've reported it and uploaded the pdf, so someone on IRC responsible could debug it, but we didn't get far enough to fix it. Otherwise I wouldn't just add another PDF Viewer to a site. But it's only the downloads section and the preview there really is not for reading, but looking if it's the right document. Anyway, thanks for caring for the project. There's a reason Mozilla chose PDF.js over writing it in C++ and that's not just because of security I think.

async56• 12 years ago

Here is telemetry data from beta users about size of PDFs http://telemetry.mozilla.org/#beta/29/PDF_VIEWER_DOCUMENT_SI... -- typical PDF size is about 200KB, and 11MB is less 20% of them.

bthorben6• 12 years ago

Filesize has nothing to do with speed most of the time ... Try the PDF Reference document [1], it's pretty fast.

The project is very active: in the three month that we investigated it, many of the pdfs that were unusable (e.g. NASAs budget report, one of the worst written PDFs I have seen so far) when we started are now fast enough. Also almost all the effort that Opera puts into the project is about performance.

I suggest you check the file again in PDF.js and report the PDF so somebody can look at it.

[1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdf...

X45• 12 years ago

I used the latest version from git and also stable releases. It would take about 3min to render (for this 11MB file only, all other pdfs, albeit smaller, load fast). It was the only PDF that was slow, all others were loaded almost instantly, however the other files were much slower too.

Donzo• 12 years ago

FPDF FTW!

chime2• 12 years ago

I love PDF.js. I built a site recently that uses embedded PDF.js to display PDFs while making it very difficult to print/copy-paste/download these documents. It is super fast, works across all modern browsers, and supports useful PDF features like bookmarks, annotations, and table of contents. It's also pretty easy to customize and theme.

andreasvc2• 12 years ago

Please don't do that, you're making the web a worse place. If you're going to sell documents, do what the academic paywalls do: display the first two pages (without any restrictions). Restrictions are just silly because if the content is on the user's computer, you know there is a way for them to get at it.

chime2• 12 years ago

I know where you're coming from and I had this exact same feeling before I embarked on this project. I've been making things for free and giving away my code/projects/services for almost two decades now so I didn't jump into this without serious consideration. I didn't want to write these details in my original post because I was just lauding the PDF.js project.

There were more than a few legal requirements for making such a system. We had to show reasonable attempts were made to prevent old copies of the data from existing anywhere i.e. old printouts, copy-pasted notes etc. The documents shown had to be timestamped and watermarked with the user's full name. Unlike the typical public scribd-style document sharing site, this was already behind a login system and 100% of all user activity was monitored with the user's full knowledge. In fact, users demand that their activity to be monitored for legal and auditing purposes.

Without going into specifics, imagine a highly skilled professional needs to e-sign that they read a training document V1.23 on date X/Y/Z. This isn't a standard Terms & Conditions agreement that everyone clicks without reading. This is something that affects the professional's abilities to make life or death decisions so they really want to read the correct version of the document. In order to meet all the legal requirements (think stuff like 21 CFR Part 11), the best technical solution turned out to be a browser-based PDF reader that disabled printing/copy-pasting/downloading. I was tasked with building that and thanks to PDF.js, I did so with almost no effort.

fdej• 12 years ago

It's fine for short documents, but not very pleasant for long math papers. PDF.js takes ~1 second to render a single page in my thesis. In Document Viewer (evince), the delay to render a page is barely perceptible (so I would guess < 0.1 seconds), and Adobe Reader renders pages instantaneously.

baby• 12 years ago

I don't know if I'm the only one to have this problem but it also shows = signs as - signs.

(it doesn't always happen and I can't find a pdf where it does that now)

async56• 12 years ago

Is it https://bugzilla.mozilla.org/show_bug.cgi?id=760997 ?

Gracana• 12 years ago

I wish it only took a second to render some of the things I've opened. I've found a lot of the manuals from Automation Direct are very slow to open and navigate. For most things I ignore pdf.js and save files to desktop so I can open them with a "proper" viewer.

anon13854• 12 years ago

There are several posts on this page touting the security benefits of PDF.js, and it's almost certainly true that PDF.js is more secure than a new pdf implementation in C or C++ would have been[1]. In the short term PDF.js makes sense.

I think there are longer term considerations here though. Web standards (HTML/CSS) and language (Javascript) were not designed to be used as a compilation target for complex programs. It was meant to be a document platform. PDF.js is fast enough to use (just about) because a massive amount of engineering time has been put into making browsers very performant. That has involved making browsers huge complex beasts that have to be written in low level unsafe languages to achieve acceptable performance[2]. By choosing to use standards that are very complicated, high level and inefficient we have made the implicit choice to require any competitive browser implementation to be highly optimised and low level. That huge pile of very complex low level code has a real security cost. Buffer overflows, dangling pointers, out of bounds reads. These things are common in browsers today[3] and will remain so while browsers have to be implemented in C++ to remain competitive performance wise.

We often engage in debates about whether Javascript/the web stack is fast enough to use for various types of software. Performance improvements are treated as an inevitability; "if it isn't fast enough today it will be tomorrow". Similar attitudes hold for missing APIs and functionality. Most people don't seem to really question what it really means for browsers to become more and more performant and more and more complex. The answer seems to be millions of lines of very complicated and low level C++.

I'm aware that Rust is one attempt to extricate ourselves from this hole, but that is years away from ever making it into a production browser, if it ever does. Meanwhile standards continue to increase in complexity and browsers continue implement those additions with large amounts of potentially unsafe C++.

I don't have any solutions to this, it's too late, we are already committed to browsers being full operating systems. But while we are all running around patting each other on the back over how 'advanced' browsers are now I do think it's worth considering the security price we are paying to make things like PDF.js possible.

[1] I think there is a bit of a false dichotomy here though. If performance is acceptable with Javascript then it presumably would have been acceptable with native languages safer than C/C++ (Java, Haskell, Go, Python, etc, take your pick).

[2] For example Chrome seems to have basically a virtual memory system implemented in the browser, with pages, heaps and pagination logic so they can use relative 32 bit pointers. ( http://article.gmane.org/gmane.os.openbsd.misc/186107 )

[3] I don't intend to pick on Firefox specifically here since these types of issues exist in all browsers, but here are some recent Firefox issues form the last month or so:

  CVE-2014-1518 Various memory safety bugs leading to possible code execution.
  CVE-2014-1523 Out of bounds read leading to crashes when viewing jpeg images.
  CVE-2014-1524 Buffer overflow when using non-XBL object as XBL leading to possible code execution.
  CVE-2014-1531 Use after free when resizing images resulting in a potentially exploitable crash.

Retric2• 12 years ago

Browsers are complex because the web is a mess not because of performance reasons. You can build a fast HTML 1.0 browser in a few lines of Java but if you want modern JavaScript + CSS + cookies + plugin suport + backwards compatibility + embedding videos + best effort rendering + ... it becomes a huge mess.

lrem• 12 years ago

Isn't HTML 1.0 actually a mess compared to 4.0? ;)

thefreeman• 12 years ago

I think that was exactly OP's point.

leeoniya• 12 years ago

This is exactly why Rust and Servo exist.

79524• 12 years ago

> We often engage in debates about whether Javascript/the web stack is fast enough to use for various types of software. Performance improvements are treated as an inevitability; "if it isn't fast enough today it will be tomorrow". Similar attitudes hold for missing APIs and functionality. Most people don't seem to really question what it really means for browsers to become more and more performant and more and more complex. The answer seems to be millions of lines of very complicated and low level C++.

Ironically, not needing to run high performance native code was a part of the original appeal of web apps. Google maps worked well however old your graphics card was. Gmail was secure even when viewed on an old version of IE.

If client side rendering is too slow, then don't render on the client. Cache the rasterized pdf as tiles up in the cloud and only read the actual document if the user selects text or zoom in. That is the only way to make massive pdf's load instantly on a slow machine.

sliverstorm2• 12 years ago

That is the only way to make massive pdf's load instantly on a slow machine.

I beg to differ. Grab an older or smaller PDF reader. One of the ones with just two features- "scroll" and "zoom"- and you will find even a terribly slow machine can keep up.

(Except when it is one of those PDFs with 30MB pictures embedded in every page)

It's the bajillion added features of dubious value, and things like using js as the backend, that has kept PDF rendering decidedly heavyweight.

When a PDF is too large for PDF.js on my little 1.0GHz laptop, I open it up in Acrobat Reader and I'm back in business.

eitland2• 12 years ago

Some of us are very happy to be able to[1] get the actual data directly to our machine without any "cloud" blurring our view, thanks : )

[1]: I have nothing against clouds, -as long as they are not mandatory that is.

async56• 12 years ago

If client side rendering is too slow, then don't render on the client. Cache the rasterized pdf as tiles up in the cloud and only read the actual document...

Some people are not comfortable with giving their financial/proprietary/secret information to third party's "cloud". And since they have to pay for "cloud", you end up paying for it somehow at the end. With client side code: 1) nobody knows what you are looking at, 2) and you don't rely on network connectivity much.

macspoofing• 12 years ago

I'm not really sure what you're getting at.

In the short term PDF.js makes sense.

What's the long term? We're not going give up on PDFs anytime soon, and having a JavaScript-based viewer will make people who just want to consume PDFs much more secure. One less vector of attack.

It was meant to be a document platform.

SO WHAT? Computers were never meant to be carried around in your pocket, the internet wasn't designed to propagate kitten memes, and Columbus never meant to land in America, yet here we are.

That has involved making browsers huge complex beasts that have to be written in low level unsafe languages to achieve acceptable performance

As opposed to which safe languages? Java? .NET?

But while we are all running around patting each other on the back over how 'advanced' browsers are now I do think it's worth considering the security price we are paying to make things like PDF.js possible.

And what was the security price for running standalone programs to read PDFs? What's the security price for ActiveX, Flash, Silverlight, Java applets?

anon13854• 12 years ago

What's the long term?

The long term is a platform that can feasibly be implemented in higher level, safer languages and still give acceptable performance. We sacrificed that when we decided to put millions of dollars of resources into making web standards run faster instead of creating something new. What we did was probably the 'easier' route at the time, but there is a cost.

SO WHAT?

Go and browse the source code of one of the main browsers. The cost of the complexity of web standards is plain to see in the ridiculous lengths browsers have to go to if they want to achieve decent performance. I gave you a list of recent security holes. The browser you are using right now almost certainly contains undiscovered buffer overflows, use after free and similar memory safety bugs. It's not just that we have created a situation where we are using big piles of unsafe code, it's that we are trapping ourselves into relying on this code for the foreseeable future because we are building a platform out of it and have made the specification of that platform so baroque that currently only C or C++ is flexible and low level enough for all the crazy performance hacks required.

Your argument seems to boil down to 'anything can be anything if we just want it hard enough', which might be true to an extent, but it does come with real costs, which was my point.

As opposed to which safe languages? Java? .NET?

.NET isn't a language, but assuming you meant C#, then yes those are safer than C or C++. I gave you CVEs for various remote execution vulnerabilities in Firefox in just the last few weeks alone that would not have been possible in memory safe languages.

And what was the security price for running standalone programs to read PDFs?

A web browser is a standalone program that reads PDFs. If it can be done 'safely' in Javascript in a web browser then it could be done in other memory safe languages as a standalone program. To answer your question though, the number of security vulnerabilities in the unsafe C code I generally use to view PDFs is quite small compared to the number of vulnerabilities in web browsers. Not surprising since browsers are orders of magnitude larger. I don't know why you want to make that comparison since it's not particularly meaningful.

What's the security price for ActiveX, Flash, Silverlight, Java applets?

You seem to just be listing technologies that are unfashionable among the web developer community. The technologies you listed all (as far as I know) had implementations written in C or C++, for performance reasons, in an era when desktop computers were far slower than even phones are today. The fact that they all had bad security records really just reenforces my point that we shouldn't be writing platforms for running remote software in C or C++ (or at least, it should be a heavily audited core with most of the implementation in something safer).

Additionally, you can't really compare the Java applet situation where Oracle clearly don't give a shit about patching in a timely manner with web browsers that are automatically updated nearly weekly by teams that take security very seriously. The Java applets security situation is what browsers would be like if they didn't have very well resourced hyper vigilant teams trying to keep them patched.

loup-vaillant3• 12 years ago

Web standards (HTML/CSS) and language (Javascript) were not designed to be used as a compilation target for complex programs.

http://asmjs.org/ — https://www.destroyallsoftware.com/talks/the-birth-and-death...

Now they are.

I don't have any solutions to this, it's too late, we are already committed to browsers being full operating systems.

When we do get to that point, and ditch the underlying MacWinuX, there's a good chance they won't be much more complex and much less secure than what they replaced. A typical MacWinuX desktop setup is already over 200 Millions lines of code. I'd be happy to drop that to a dozen million lines instead (even though 20K are probably closer to the mark http://vpri.org/html/work/ifnct.htm). It also shouldn't be much slower than current native applications.

Heck, it may even be significantly faster. Without native code, hardware doesn't have to care about backward compatibility any more! Just patch the suitable GCC or LLVM back end, and recompile the brO-Ser. New processors will be able to have better instruction sets, be tuned for JIT compilation… The Mill CPU architecture for instance, with its low costs for branch mispredictions, already looks like nice target for interpreters.

---

I do think it's worth considering the security price we are paying to make things like PDF.js possible.

Remember the 200 million lines I mentioned above? We're already paying that security price. For a long time, actually.

---

That said, I agree with your main point: the whole thing sucks big time, and it would be real nice if we could just start over, and have a decent full featured system that fit in, say 50.000 lines or so. Of course, that means forgoing backward compatibility, planning for many cores right away… Basically going back to the 60s, with hindsight.

Alas, as Richard P. Gabriel taught us, it'll never happen.

peterashford2• 12 years ago

I don't think you have to forgo backwards compatibility. Implement a standard VM and library set that everyone can compile to. Implement HTML/JS as a module in the new system. Problem solved.

martindale• 12 years ago

Ah, thanks for posting Gary's talk. Great stuff.

anon13854• 12 years ago

Heck, it may even be significantly faster. Without native code, hardware doesn't have to care about backward compatibility any more! Just patch the suitable GCC or LLVM back end, and recompile the brO-Ser. New processors will be able to have better instruction sets, be tuned for JIT compilation… The Mill CPU architecture for instance, with its low costs for branch mispredictions, already looks like nice target for interpreters.

Heh, I hope you appreciate the irony in that one. On the one hand we have people arguing that we have to stick with the existing web platform for backwards compatibility reasons, but on the other you are suggesting it would be easy to switch the entire world to new totally incompatible processor architectures to make aforementioned web platforms performant.

Scaevolus• 12 years ago

Chrome's PDF renderer runs inside a NaCl sandbox, where any potentially unsafe machine operations are checked before execution. That's arguably _harder_ to break out of than Firefox's Javascript sandbox.

comex• 12 years ago

I would consider it somewhat harder. However, that's only after assuming that the author of the document has managed to get the PDF reader to start running arbitrary C and JavaScript code within the sandboxes, respectively. Because JavaScript is a fundamentally memory safe language, it is drastically less likely for a document parser written in JavaScript to end up running arbitrary code from the document than the equivalent in C.

Not that it matters in this case, since an attacker can just hand you a HTML page and run JavaScript that way, but it's worth noting that parsing in a high-level language is an accomplishment in general.

andrewstuart22• 12 years ago

Web standards (HTML/CSS) and language (Javascript) were not designed to be used as a compilation target for complex programs. It was meant to be a document platform.

Computers were designed to do math, not word processing or gaming or mapping of massive datasets into comprehensible reports. Attitudes like this are toxic to progress, in my opinion, and far too common.

anon13854• 12 years ago

Well, I've yet to see a video player done in a browser that didn't use the <video> element, or call out to some native plugin (flash, or realplayer, quicktime etc back in the day). I wouldn't be surprised if it had been attempted by just changing the contents of an <img> or something, but I don't think anybody would call that a sane way to play video. So clearly the original document system was not actually suitable for building things like video players - that functionality had to be added in later (implemented in native C++ of course) and exposed with an API because the web platform itself wasn't powerful enough to do it.

Anyway, I never said the web as an app platform can't be done. I'm asking if it is a good idea, and if we are fully considering the tradeoffs involved (i.e. a bit of 'engineering'). I don't find 'because we can' a great reason when it comes to things that affect the lives of most computer using people. A higher level of responsibility is involved in these situations than somebodies experimental spare time github repos.

I could sit here and think of a dozen feasible ways to get water from ground level to the first floor of my house. It wouldn't be 'toxic to progress' to point out that there are better ways than an archimedes screw powered by a horse in the garden. Thinking about better ways to do things rather than just blundering forwards with the first idea that comes to mind is exactly how progress is made.

pm215• 12 years ago

"OK on 96% of PDFs" is all very well, but that means that almost 1 document in 20 is performing poorly. It only takes a few slow-rendering documents to make me switch to something else, so if I look at (say) 3 PDF files a day then you've probably lost me as a user within a fortnight.

kemayo• 12 years ago

That does assume that the 1 in 20 which perform poorly are randomly distributed across the set of PDFs. It seems at least plausible that these would actually be grouped up by type somehow (e.g. it mentioned that the worst one they found was a huge vector map of the Lisbon subway system), and thus it would probably be the case that a user would either encounter them far less than that 1 in 20 or far more, depending on their own usage patterns.

reitanqild• 12 years ago

Still faster than the download - wait for Acrobat/Foxit Reader - wait for marginally faster loading document cycle anyway isn't it?

acqq15• 12 years ago

Please do a google search to

    building plan filetype:pdf

(edit: I actually don't know the search terms that would return the real architectural plans and not some texts, I guess somehow Google ranks PDFs with a lot of texts much higher than the documents with drawings -- but I want to point to these actually! If it's true that Google prefers "a lot of text" documents then attempting to googe to get the examples is a good method to miss most of the documents with the real problems!)

Then try to actually look at every page of such documents with pdf.js. The first I get is

http://www.nist.gov/el/nzertf/upload/NZERTF-Architectural-Pl...

Try it. You will want to throw your fast computer thorough the window. Then when you manage to calm down you'll try to configure your browser to never invoke pdf.js again, if you know that you need to work with such documents.

If you want a realistic benchmark, compare the speed of rendering these documents with Adobe's or some other native renderer.

I'm not a building architect but I at least don't live in "we don't draw anything significant in our documents" bubble. I know they worry for their potential customers. Forced pdf.js is a huge setback for them. If they would be able to tell the browser in the html "please don't use pdf.js for this one" they would be much happier.

bthorben6• 12 years ago

I just tried the mentioned document in the viewer on http://mozilla.github.io/pdf.js/web/viewer.html

I agree that the speed is a lot worse than in Preview.app for example, but it's also not unusable. I will look at it in more detail tomorrow

acqq15• 12 years ago

Try to move through the pages, don't stay on the first one! I have the 22nm i7 CPU here and compared to the work with Adobe PDF reader it's just horrible having to use pdf.js.

I must however admit that I'm not able to easily construct a Google search for more such documents, but I know a lot of people who work only with such -- they just can't work with pdf.js.

Does your benchmark measure the time to actually display everything on every page (what the human looking at all the pages must do), or just the time until the browser is responsible?

Edit: inspired from other comments, it seems that at least search for "math plots filetype:pdf" returns more guaranteed problems like

http://www.engageny.org/sites/default/files/resource/attachm...

Still it's hard to find slow PDFs with certainty just by using Google.

bgirard4• 12 years ago

I just profiled your example: http://people.mozilla.org/~bgirard/cleopatra/#report=4b995cc...

Looks like it could be running much faster:

* 20% of the time is spent copying the canvas because someone is, likely erroneously, holding a reference to the canvas. Looking into it: https://bugzilla.mozilla.org/show_bug.cgi?id=1007897

* 10% of the time is spent waiting on display transactions swaps because canvas isn't triple buffered.

* PDF.js is not getting empty transaction (canvas draw optimizations).

That's just from a quick profile. I'm sure there's a ton more things that could be improved.

acqq15• 12 years ago

Thanks! Good work! It's of much more benefit to analyze slow pdfs than to construct the "proofs" that short and simple pdfs are displayed "fast enough" (but I understand that the later feels so good). Especially since it seems that not only pdf.js will benefit from analyzing the slow ones -- if I understand you traced the problems to the cpp code of the browser? That would mean that even non-pdf-js stuff will be faster once it's fixed, is that correct?

acqq15• 12 years ago

A little OT, but since you're so good at profiling Firefox, I have one more interesting "a lot of real work" page that will maybe inspire you or somebody you know:

http://bellard.org/jslinux/

This emulates in JavaScript the x86 and necessary hardware to really boot Linux 2.6.20(!) On my computer, Opera 12.17 will show "booted in 2.8 seconds," versus Firefox 29 on which it will be "booted in 7.9 seconds." That's 2.8 times slower.

TwoBit2• 12 years ago

I tried loading that and it worked pretty well for me. Not fully native speed, but just a couple seconds to draw complex pages. Certainly not a "throw the computer out the window" experience.

acqq15• 12 years ago

It's really minutes to see all the drawings, i7, Win 8.1, FF 29 (to compare the CPU speeds, jslinux boots in 7.9 secs on my computer). Adobe Reader is immediate to see all the 20 pages.

Have you tried to see all the pages, all the drawings? How many minutes you needed, on which setup? Are you using Firefox? Does it use pdf.js? Is it something OS dependent, or you just didn't look at all the pages?

Now I see, Gracana mentions manuals on AutomationDirect.com. Look at this one for example:

http://www.automationdirect.com/static/specs/dl0506select.pd...

andyl• 12 years ago

Does anyone know of a good tool for PDF generation in JavaScript? In Ruby, I use Prawn, which is great. Is there a Prawn-like library for JavaScript?

gmac• 12 years ago

https://github.com/devongovett/pdfkit

(I've also been working on something lower-level — basically support for creating a PDF file out of its raw sections — but it's not quite yet released).

yeukhon• 12 years ago

The performance is fine but when I have to open PDF files with foreign language neither Adobe or PDF.js can do that well. Adobe will require me to have the font package downloaded. I don't think there is such package for PDF.js which forces me to download the PDF.

abhishivsaxena• 12 years ago

They render fine if fonts are embedded; granted there are many pdfs which don't. But then it's the producers which are to blame.

malandrew• 12 years ago

Is PDF.js used by Chrome? The reason I ask is because the safe script plugin blocks rendering of all pdfs not from a trusted domain. I find this behavior quite frustrating, since PDFs afaik don't contain (or typically contain tracking code or keep executing code after the initial render of the document).

azakai4• 12 years ago

No, Chrome ships a proprietary PDF viewer as native code (Foxit).

tectonic• 12 years ago

I've had a really good experience implementing a BeeLine Reader PDF coloring algorithm with PDF.js. It was surprisingly easy to work with.

http://www.beelinereader.com/pdf

nnethercote5• 12 years ago

I made some big improvements to pdf.js's speed and memory usage a few months ago, particularly for black and white scanned images -- for one 226 page document I saw ~8x rendering speed-ups and ~10x memory usage reductions.

Details are here: https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-an.... These are present in Firefox 29 which only just came out, so if you're seeing bad performance and you're still on 28 or earlier, an upgrade might help.

If you have particular PDFs that cause pdf.js to run slowly, please file bugs about them at bugzilla.mozilla.org under the "Firefox" product and the "PDF Viewer" component. PDF is a large, complicated format, so there are many corner cases that the pdf.js developers are unlikely to see without help. Every improvement I made came about from profiling PDFs that people had reported as causing problems.

TwoBit2• 12 years ago

I have FireFox 29 and those pages rendered fairly fast for me. Maybe a couple seconds per first viewing of a page, worst case.

nnethercote5• 12 years ago

Which pages do you mean by "those pages"?

voltagex_• 12 years ago

Reporting bugs in Firefox is intimidating to say the least. Will a bug filed at GitHub like https://github.com/mozilla/pdf.js/issues/4761 still reach the right place?

bgirard's profiling work in this thread has been amazing, but I don't think I have the knowledge to interpret the profiler results well enough to file bugs on slow PDFs. A way to post "slow" PDFs to be picked up by pdf.js developers would help.

nnethercote5• 12 years ago

Will a bug filed at GitHub like https://github.com/mozilla/pdf.js/issues/4761 still reach the right place?

Filing at Bugzilla will probably give you a wider audience. This can be useful if the underlying perf problem is with Firefox rather than pdf.js. Don't worry about getting some of the Bugzilla fields wrong, it happens all the time and people don't mind. A good description of the problem (with steps to reproduce) is the most important thing.

If you're still intimidated, filing something with pdf.js's GitHub tracker is a lot better than nothing.

async56• 12 years ago

Filing nothing will not be helpful for sure. Creating a report in any related bug reporting system will bring developer's, QA's or manager's attention. Just provide enough information, so somebody else except you can reproduce the problem.

p013• 12 years ago

I <3 your work on the JBIG2 decoder!

When I started to work on JBIG2, it was kind of irritating as you were often one week ahead of me. When I started to make some optimizations I would see a PR from you with the exact same things. :p

It's really nice to contribute to PDF.js. Overall between your work and Opera's contributions the font caching, images decoders and color conversions got significantly faster! And there is still a lot we can do.

nnethercote5• 12 years ago

Heh, sorry for the overlap :)

keeperofdakeys• 12 years ago

Since you've done some work on it, I'll assume you understand the architecture well. My biggest gripe with pdf.js is that resizing triggers a full page reload, since it has to redraw the canvas. Whereas this is instant on other pdf readers. Would there be any workarounds for this? Or will we be stuck with this behaviour till "pdf.js 2.0".

Edit: This is an example of what I'm talking about https://github.com/mozilla/pdf.js/issues/3853

anon3445• 12 years ago

Experimenting with SVG might be a good option here. Or maybe, implementing a mixture of canvas with SVG, might improve the performance.

nnethercote5• 12 years ago

Since you've done some work on it, I'll assume you understand the architecture well.

Alas, no :) My work was basically a few surgical strikes in which I learned a lot about a few small corners, but my overall understanding of the code base is pretty weak.

I recommend filing a new issue here: https://github.com/mozilla/pdf.js/issues/new

shmerl• 12 years ago

When used with heavy PDFs which basically contain tons of images (like scanned books) PDF.js is noticeably slower than native plugins (like Kparts plugin with Okular on KDE) used with Firefox. For more lightweight PDFs it's acceptable.

hendry• 12 years ago

What does it matter? PDF.js broke quality printing to CUPs, so it's a bit of joke if you break that printing use case.

https://bugzilla.mozilla.org/show_bug.cgi?id=932289

coldtea• 12 years ago

This is probably the worst benchmark I ever read. Talk about fitting the data to your desired predetermined result.

I mean, only check just "popular" PDFs? What about all the people that work with PDFs and are sent custom files for their enterprise/office/design agency etc, and not "popular" stuff. Has he checked what the shape of the distribution curve for popular vs "long tail" PDFs are?

Second, using the time to load their intro page as a baseline? How's that relevant? Just because he has this arbitrary subjective idea that "up to 3x that time gives a good user experience"? How about comparing to the time Actobat/Preview take?

Lastly, just measures loading the pdf? How about going through the pages?

p013• 12 years ago

The code of the benchmark is open source. Go check how it works and by all mean send a pull request. Any improvement there will shift focus where it matters most and help every user of PDF.js ( in Firefox itself and in the various extensions and services built on top of PDF.js ).

The benchmark measures 5x the rendering time of every single page of every single PDF.

The problem with benchmarking the "not popular" PDFs is that they're not available outside of their enterprise/office/design agency etc... But if you have any you can share publicly, please file an issue on the Github repository of PDF.js

Some people mentioned Mozilla' Telemetry. Unfortunately it is too limited for this kind of research as it can only report enum values. Using Telemetry would need some work to get a baseline/reference for each computer and the results would take weeks or months to come back due to the lag between the master version of PDF.js and the one bundled in Firefox.

We compared PDF.js against native viewers. The performance was worse but we can fix this. We already started. For the other things e.g.: rendering quality, color conversions, accessibility, text selection, binary footprint, zoom & scroll, ... PDF.js was on par or better.

camus2• 12 years ago

While PDF is a great tech demo in practice,unless one is using it for short documents,it doesnt work very well.That's why google did what it did with doc,render the pdf as an image them put a transparent text over it. It's a better approach if one has good servers. because frankly one cant expect the browser to behave like acrobat reader and be as performant as native applications when trying to render 20MB pdfs (and a lot of books are that big,this is not an rare use case).

Aardwolf• 12 years ago

Not very fast... when loading a big PDF, before the save button can be used, it needs to render the whole thing first. I don't understand why, because all it has to do is save the file which it already has.

p013• 12 years ago

I believe this is a shortcoming of the default viewer that comes with PDF.js. 'coz as you say saving the file on disk has nothing to do with PDF.js itself. Bare in mind that PDF.js works in older browsers ( IE8 and 9, and even older versions of Opera, Firefox, ... ) so this might drag down the default viewer a bit.

Beside, if you know before hand that you want to save the PDF, surely you can right/Cmd click the link and save the file right away.

Anyhow, if we - Opera - decide to use PDF.js as the default PDF renderer for the Desktop browser, we will roll our own viewer which can use fancy pancy features like: <a href=# download>Save</a>

rglover• 12 years ago

Semi-related, but has anybody found a decent PDF generator for JS? Something where you can get a decent quality PDF (none of the screenshot via phantom.js stuff) that's text, a few tables, and a decent layout? Closest example would be an invoice for something.

P.S. This would need to work with Node/Meteor.

How fast is PDF.js?

Related Stories