5 ms·

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

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-and-faster-pdf-js/ 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.

TwoBit 12y 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.
- nnethercote 12y ago
  Which pages do you mean by "those pages"?
  - acqq 12y ago
    Whatever he means, there are also a lot of slow PDF's when googling: controller site:automationdirect.com filetype:pdf
voltagex_ 12y 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 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.
- nnethercote 12y ago
  > Will a bug filed at GitHub like https://github.com/mozilla/pdf.js/issues/4761 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.
- async5 12y 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.
p01 12y 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.
- nnethercote 12y ago
  Heh, sorry for the overlap :)
keeperofdakeys 12y 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 https://github.com/mozilla/pdf.js/issues/3853
- anon3445 12y ago
  Experimenting with SVG might be a good option here. Or maybe, implementing a mixture of canvas with SVG, might improve the performance.
- nnethercote 12y 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 https://github.com/mozilla/pdf.js/issues/new

TwoBit 12y 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.

nnethercote 12y ago
Which pages do you mean by "those pages"?
- acqq 12y ago
  Whatever he means, there are also a lot of slow PDF's when googling: controller site:automationdirect.com filetype:pdf

voltagex_ 12y 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 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.

nnethercote 12y ago
> Will a bug filed at GitHub like https://github.com/mozilla/pdf.js/issues/4761 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.
async5 12y 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.

p01 12y 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.

nnethercote 12y ago
Heh, sorry for the overlap :)

keeperofdakeys 12y 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 https://github.com/mozilla/pdf.js/issues/3853

anon3445 12y ago
Experimenting with SVG might be a good option here. Or maybe, implementing a mixture of canvas with SVG, might improve the performance.
nnethercote 12y 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 https://github.com/mozilla/pdf.js/issues/new