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