bthorben

> 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?

It "only" benchmarks the rendering, all the overhead the viewer produces is not shown. That is intentional, as we will create our own viewer anyway

BTW: PDF.js in FF is typically slower than in Opera / Chrome, all these benchmarks used Opera

MuPDF is a very nice piece of software, but it's GPL licensed. As I understand it, this basically prevents MuPDF from actually being used in commercial software ... unless of course we would make the software open source ...

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

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.

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...

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.