Hacker News Reader

Comment by nnethercote | Hacker News Reader

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.

View on HN

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.

Heh, sorry for the overlap :)

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

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

> 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

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.

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

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.

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

Which pages do you mean by "those pages"?

Whatever he means, there are also a lot of slow PDF's when googling:

   controller site:automationdirect.com filetype:pdf

Reply on news.ycombinator.com