3 ms·
Sorry, but this is definitely a case where code speaks louder than words. PDF.js was a miracle for its time, and the guys behind it definitely aren't amateurs.
by hosay123 12y ago
Sorry, but this is definitely a case where code speaks louder than words. PDF.js was a miracle for its time, and the guys behind it definitely aren't amateurs.
The PDF standard is far richer than the SVG object model, and not to mention SVG performance in just about every browser except for Chrome has always sucked balls.
Using canvas seems a solid trade off - pay upfront with RAM in order to consistently render and cache a page once, or try to jerry-rig some nasty translation to SVG that's painfully slow to zoom or scroll, and no longer renders consistently across browsers.
- userbinator 12y agoI'm not doubting that PDF.js is an amazing work of effort -they have essentially replicated the entire PDF rendering engine - but that considering a different approach, with a different set of tradeoffs, could yield a solution requiring far less memory and still have practical use. When considering memory, keep in mind that using too much - combined with every other process the user could be running - means a higher chance of needing to use the swapfile, and then any performance advantage otherwise gained disappears rather quickly. It should be noted that browsers already cache rendered page images (from HTML) in memory and are very good at that, along with rendering HTML.
- TheLoneWolfling 12y ago> SVG performance in just about every browser except for Chrome has always sucked balls. That seems like a self-fulfilling prophecy to me. If it's broke, fix it. Don't do clunky workarounds that mean that it's less likely to be fixed in the future.