11 ms·

An even slimmer pdf.js

166 points by AndrewDucker 12y ago

Goopplesoft 12y ago
Out curiousity of the process: why wouldnt something like this show up in a earlier release?
- zz1 12y ago
  Likely because it follows the highly organized release cycle Firefox has adopted a couple of years ago. If the new pdf.js is included right now in Nightly, which is necessary in order to verify its integration in the browser, its interaction with other elements and to ensure a long enough test phase on rendering before it lands on release channel… well, if it is right now in Nightly, let us do the math: * Firefox (release channel) is now 30 * Beta is 31 * Aurora is 32 * Nightly is 33 That's why.
  - nnethercote 12y ago
    Yep. The calander is here: https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar
userbinator 12y ago
pdf.js uses HTML canvas elements to render each PDF page If it's doing this for text or vector graphics content, then I'm of the strong opinion that they're doing it very wrong - HTML already has facilities to render text, and browsers support SVG for vector graphics. The canvas elements should be used for bitmap images only, since that's what they were designed for. Edit: this thought occurred to me because the Chinese site Baidu has an online document viewer which basically converts uploaded PDFs into HTML and does it without needing to canvas everything; here's an example: http://wenku.baidu.com/view/544340cea1c7aa00b52acb38.html http://wenku.baidu.com/view/544340cea1c7aa00b52acb38.html In my Chrome it takes ~60M sitting on the first page, complete with all the other pieces of the page (including ads). Scrolling through all the pages of the document, it ends up at ~130M. Here is the original document: http://www.promelec.ru/pdf/MBI5030%20Preliminary.pdf http://www.promelec.ru/pdf/MBI5030%20Preliminary.pdf When it is opened in PDF.js (v1.0.277) to the first page, I see ~95M and scrolling through all the pages makes it peak at ~270M; and this is just for the PDF viewer only, so there is clearly much room for improvement.
- benhoyt 12y ago
  It's a good thought, and it does seem a much better way to go at face value. However, I strongly suspect there are good technical reasons why you basically need to use canvas, to get the complete, pixel-perfect control over the layout and font rendering that you'd need for PDFs.
  - userbinator 12y ago
    to get the complete, pixel-perfect control over the layout and font rendering that you'd need for PDFs. I suspect this is part of the problem too - the desire to render every pixel of fonts the same as the native application. But honestly, 99.9% of the time I'm reading a PDF, I don't care if each pixel is in exactly the same place as it would be in some other reader application so long as I can read the content, and would be willing to sacrifice that if it meant a drastic decrease in memory consumption (and possibly better performance.) That doesn't mean a "precise mode" is a bad idea, so maybe make this an option - you can either have pixel-perfect rendering but use more memory and CPU, or have a "close enough" rendering that doesn't.
    - masklinn 12y ago
      If you don't care you should feel free to replace pdf.js with a degraded version, but I'd expect something which claims to render PDFs to actually do that.
    - mhaymo 12y ago
      Seems to me that the development time spent maintaining two different modes might be better spent simply improving the efficiency of the one correct version.
    - jerf 12y ago
      "But honestly, 99.9% of the time I'm reading a PDF, I don't care if each pixel is in exactly the same place as it would be in some other reader application so long as I can read the content" No, you don't actually want that. I've seen this in Linux where a PDF gets rendered with the wrong font because the correct one wasn't on my system or embedded in the PDF. It becomes illegible. PDFs are deeply pixel perfect in specification; you can't just decide to not worry about that anymore and expect anything legible to come out the other side. It is not HTML under the hood; it's a printer format under the hood.
gabemart 12y ago
The reduction in memory usage seems impressive for large PDFs, but peak usage of 695MiB to display a 14-page pdf [1] still seems like loads of memory. On my machine, a native reader (Foxit) [2] takes ~30MiB. [1] http://cdn.mozilla.net/pdfjs/tracemonkey.pdf http://cdn.mozilla.net/pdfjs/tracemonkey.pdf [2] http://www.foxitsoftware.com/Secure_PDF_Reader/ http://www.foxitsoftware.com/Secure_PDF_Reader/
- masklinn 12y ago
  1. You're using a completely different system (at all levels of resolution) so the comparison hardly makes sense 2. The browser measurement includes the browser's overhead. On my non-retina MBP a freshly started Firefox 30 yields an RSS of 240MB (Preview — the system's default image and PDF viewer — is 16MB and grows to 44MB on opening the Tracemonkey PDF). And that's with just Firebug and the WD toolbar, we've got no idea what manners of extensions or building options OP has. And for reference, opening the Tracemonkey PDF grows Firefox's RSS from 240 to 350MB. 3. The article's measurements includes rendered and cached pages, opening the TraceMonkey PDF grows my Firefox's RSS to 350MB but browsing to the end (and ensuring every page is loaded) ends up with a 480MB RSS, a behaviour which also exists (to a lower extent) on Preview, which grows from 44MB RSS to 85MB (then back down to 62MB) 4. Finally, the article specifically notes that "pdf.js still uses substantially more memory than native PDF viewers."
  - rplnt 12y ago
    It does make sense when you look at it as a user. The result is the same.. requirements are not. With one you need a dedicated application, with other you need excessive amounts of memory. Also, there's about:memory available in firefox for quite detailed memory break-down.
    - masklinn 12y ago
      > It does make sense when you look at it as a user. No. You misunderstand point 1, I'm not saying comparing Firefox to Foxit as PDF viewers is nonsensical[0], I'm saying GP comparing the number he gets on his machine to the numbers provided by OP is not sensible: OP uses 64b Firefox on 64b OSX on an rMBP (the retina part quadrupling the size of the render target if software is compatible) while GP uses unknown bitness Foxit on unknown bitness Windows on unknown hardware. That's a fractally nonsensical comparison, just about everything which can be changed is changed. A somewhat real comparison would require that GP install a FF33 nightly on his machine and look at what happens there, and only looks at the difference between browser open and browser open + PDF. That would give the browser and PDF.js's overhead over opening PDFs in a native client. > Also, there's about:memory available in firefox for quite detailed memory break-down. Which is not what's in OP's graphs, not what GP compares his numbers to, and not relevant to my comment. [0] although it kind-of is, firefox bundles a PDF viewing utility for convenience, it's not a PDF viewer (unless you're in firefox os maybe?)
hbogert 12y ago
So.. the author is focusing on metrics - the memory usage. Basicly what's being done is release the caching sooner. Well what if a user's usecase scenario is such that he's looking at 2 pages after another a few times which have 10 pages in between.. This would cause a lot more rerenderings than before, making CPU go up. I'm not sure if I want to trade memory for CPU when running on battery
- nnethercote 12y ago
  Software is full of trade-offs. If slightly pessimizing an unusual case is the cost of drastically improving an extremely common case, then I'm happy to do that.
  - pessimizer 12y ago
    Switching between two non-consecutive pages in a pdf is not an unusual case.
    - nnethercote 12y ago
      Switching by scrolling, or by jumping directly to the pages using a page selector? The latter case will be handled fine by a 10 page cache. Anyway, I think this fear is overblown. The CPU cost of rendering a single page isn't that high.
Pacabel 12y ago
This incident should serve as a very good lesson to those in the Firefox community who often claim that memory and performance problems don't exist, even after numerous users report experiencing such problems. Such memory and CPU consumption problems are often blamed on vague "third-party extensions", even when they happen with fresh installations on systems that have never before had Firefox installed. Or they're otherwise blamed on the user somehow, even when the user is engaging in a perfectly reasonable workflow. And even if the problems don't happen on one system, they very well could be happening on another system, as this very incident shows quite well. This part of the article is particularly relevant: "Shortly after that, while on a plane I tried pdf.js on my Mac laptop. I was horrified to find that memory usage was much higher than on the Linux desktop machine on which I had done my optimizations. The first document I measured made Firefox’s RSS (resident set size, a.k.a. physical memory usage) peak at over 1,000 MiB. The corresponding number on my Linux desktop had been 400 MiB!" This matches very well with what so many Firefox users describe as happening to them. The memory consumption ends up skyrocketing to well above what it reasonably should be. Gigabytes of memory are unjustifiably consumed. Perhaps now instead of ridiculing or ignoring people who report such issues, those in the Firefox community will perhaps do the responsible thing and take them seriously. It should be very obvious now that memory consumption problems can happen on one system, while not happening on another.
- nnethercote 12y ago
  Hi, Pacabel! Can you give specific examples of this ridicule? While I don't claim that everything is perfect, my experience is that for the past few years Mozilla has taken Firefox performance issues extremely seriously. For example, I started a project called MemShrink exactly three years ago to reduce Firefox's memory consumption. In fact, I even wrote a blog post today that discussed the major improvements from the past year, and what areas we still fall short on: https://blog.mozilla.org/nnethercote/2014/06/16/memshrinks-3rd-birthday/ https://blog.mozilla.org/nnethercote/2014/06/16/memshrinks-3.... And if you want more detail about this particular effort, you can read the 70+ status reports I've written in those three years here: https://wiki.mozilla.org/Performance/MemShrink https://wiki.mozilla.org/Performance/MemShrink. And since you mentions extensions, you could also read about how we solved the vast majority of the memory leaks that involved extensions here: https://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-plugs-the-add-on-leaks/ https://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-p.... That was almost two years ago. As for pdf.js, here's the bug I filed last year about it using too much memory: https://bugzilla.mozilla.org/show_bug.cgi?id=881974 https://bugzilla.mozilla.org/show_bug.cgi?id=881974. The title of the bug is "pdf.js uses too much memory". No ridicule or ignoring the problem there. MemShrink is just one of numerous performance-related projects that have been undertaken at Mozilla over the past few years. I'm sure with a little Googling you could find out about some of the others.
annnnd 12y ago
I don't want to sound negative and I certainly don't want to start a war here. I also really appreciate what Mozilla is doing and I am an otherwise happy user of FF on both desktop and mobile. That said, FF memory usage (not just pdf.js) is sometimes just insane. Granted, I only have 2GB on this Linux, but FF invariably eats most of it (with just 10-20 tabs) if left running for long periods. Interestingly enough, once I restart FF and reopen the same tabs, memory usage is far lower. Memory leak? Inefficient caching? Who knows... Every now and then there is a version of FF that claims to be using less memory, but in my experience the differences have been negligible. So as far I am concerned memory friendly FF is something like fast Java... I am still waiting to meet one of these beasts in the wild. :)
- Gracana 12y ago
  Is firefox actually using memory in such a way that other programs can't use it, or is it simply making efficient use of memory but caching everything it can?
  - annnnd 12y ago
    VM starts swapping so much that it is not usable anymore.
    - Gracana 12y ago
      Ah, okay. By the way, I was just fiddling around and found "about:memory", which contains a lot of interesting information about memory usage and a couple tools for cleaning up memory. Might be interesting to look at when the browser starts bogging down your system.
      - annnnd 12y ago
        "about:memory" is probably great, but it is too detailed for someone who is not familiar with FF internal architecture. The way I see it it is mainly useful for FF developers. I like "about:addons-memory" (available if you install https://addons.mozilla.org/en-US/firefox/addon/about-addons-memory/ https://addons.mozilla.org/en-US/firefox/addon/about-addons-...).
pjc50 12y ago
Useful reminder: you can set "pdfjs.disabled" in about:config to turn it off and redirect PDFs to a native app of your choice. The concept of rendering PDFs in the browser isn't fundamentally bad, but large files crashing the browser is a disaster. This happened with Adobe as a plugin and it continues to happen. Now if someone can provide a means of un-embedding streaming video as well, that would be very useful.
- fulafel 12y ago
  This is pretty risky as native PDF readers are among the most targeted malware infection vectors. At least make sure you don't have Adobe Reader if you decide to risk this.
- TheLoneWolfling 12y ago
  > you can set "pdfjs.disabled" in about:config to turn it off Already do that. Bonus: I'm on a laptop intermittently without internet access, and can open up PDFs to read offline without having them be lost when my browser crashes. > Now if someone can provide a means of un-embedding streaming video as well, that would be very useful. Really hard to do, unfortunately. For HTML5 video, maybe (and I'd love it if someone came up with something of the sort), but for flash video the problem is that there isn't really any standard for flash video players, so you can't really parse the flash file to figure out what video to play without running it. That being said, maybe some sort of local proxy that recognizes when a video file is requested by flash and reports a 404 to it, with a popup "do you wish to open this link in a local player". But that way lies madness.
  - ffreire 12y ago
    This could, perhaps, initially be implemented as a plugin that inspected/listened for link clicks and forwarded them to your application of choice. I believe VLC is capable of opening streams without too much hassle (not sure about other players). Sounds like a fun weekend project, at any rate!
    - TheLoneWolfling 12y ago
theblackswan 12y ago
this is good.
jeroen 12y ago
The current release is v1.0.68, v1.0.277 is a pre-release, so this will probably be in the next release or the one after that. ( https://github.com/mozilla/pdf.js/releases https://github.com/mozilla/pdf.js/releases ) I have recently switched my project from v0.8.1013 (from feb 2014) to v1.0.68 and rendering times have improved enormously. Good to see that there are more improvements coming.
_quasimodo 12y ago
I wonder if it is feasible to compress cached canvases, either as part of pdf.js or natively in firefox.
kuntau 12y ago
Maybe Chrome team should have this MemShrink meeting every once in a while. At the current state it will eat every memory available be it 8GB or 16GB system.

166 points by AndrewDucker 12y ago

Goopplesoft 12y ago

Out curiousity of the process: why wouldnt something like this show up in a earlier release?

zz1 12y ago
Likely because it follows the highly organized release cycle Firefox has adopted a couple of years ago. If the new pdf.js is included right now in Nightly, which is necessary in order to verify its integration in the browser, its interaction with other elements and to ensure a long enough test phase on rendering before it lands on release channel… well, if it is right now in Nightly, let us do the math: * Firefox (release channel) is now 30 * Beta is 31 * Aurora is 32 * Nightly is 33 That's why.
- nnethercote 12y ago
  Yep. The calander is here: https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar

userbinator 12y ago

pdf.js uses HTML canvas elements to render each PDF page If it's doing this for text or vector graphics content, then I'm of the strong opinion that they're doing it very wrong - HTML already has facilities to render text, and browsers support SVG for vector graphics. The canvas elements should be used for bitmap images only, since that's what they were designed for. Edit: this thought occurred to me because the Chinese site Baidu has an online document viewer which basically converts uploaded PDFs into HTML and does it without needing to canvas everything; here's an example: http://wenku.baidu.com/view/544340cea1c7aa00b52acb38.html http://wenku.baidu.com/view/544340cea1c7aa00b52acb38.html In my Chrome it takes ~60M sitting on the first page, complete with all the other pieces of the page (including ads). Scrolling through all the pages of the document, it ends up at ~130M. Here is the original document: http://www.promelec.ru/pdf/MBI5030%20Preliminary.pdf http://www.promelec.ru/pdf/MBI5030%20Preliminary.pdf When it is opened in PDF.js (v1.0.277) to the first page, I see ~95M and scrolling through all the pages makes it peak at ~270M; and this is just for the PDF viewer only, so there is clearly much room for improvement.

benhoyt 12y ago
It's a good thought, and it does seem a much better way to go at face value. However, I strongly suspect there are good technical reasons why you basically need to use canvas, to get the complete, pixel-perfect control over the layout and font rendering that you'd need for PDFs.
- userbinator 12y ago
  to get the complete, pixel-perfect control over the layout and font rendering that you'd need for PDFs. I suspect this is part of the problem too - the desire to render every pixel of fonts the same as the native application. But honestly, 99.9% of the time I'm reading a PDF, I don't care if each pixel is in exactly the same place as it would be in some other reader application so long as I can read the content, and would be willing to sacrifice that if it meant a drastic decrease in memory consumption (and possibly better performance.) That doesn't mean a "precise mode" is a bad idea, so maybe make this an option - you can either have pixel-perfect rendering but use more memory and CPU, or have a "close enough" rendering that doesn't.
  - masklinn 12y ago
    If you don't care you should feel free to replace pdf.js with a degraded version, but I'd expect something which claims to render PDFs to actually do that.
  - mhaymo 12y ago
    Seems to me that the development time spent maintaining two different modes might be better spent simply improving the efficiency of the one correct version.
  - jerf 12y ago
    "But honestly, 99.9% of the time I'm reading a PDF, I don't care if each pixel is in exactly the same place as it would be in some other reader application so long as I can read the content" No, you don't actually want that. I've seen this in Linux where a PDF gets rendered with the wrong font because the correct one wasn't on my system or embedded in the PDF. It becomes illegible. PDFs are deeply pixel perfect in specification; you can't just decide to not worry about that anymore and expect anything legible to come out the other side. It is not HTML under the hood; it's a printer format under the hood.

gabemart 12y ago

The reduction in memory usage seems impressive for large PDFs, but peak usage of 695MiB to display a 14-page pdf [1] still seems like loads of memory. On my machine, a native reader (Foxit) [2] takes ~30MiB. [1] http://cdn.mozilla.net/pdfjs/tracemonkey.pdf http://cdn.mozilla.net/pdfjs/tracemonkey.pdf [2] http://www.foxitsoftware.com/Secure_PDF_Reader/ http://www.foxitsoftware.com/Secure_PDF_Reader/

masklinn 12y ago
1. You're using a completely different system (at all levels of resolution) so the comparison hardly makes sense 2. The browser measurement includes the browser's overhead. On my non-retina MBP a freshly started Firefox 30 yields an RSS of 240MB (Preview — the system's default image and PDF viewer — is 16MB and grows to 44MB on opening the Tracemonkey PDF). And that's with just Firebug and the WD toolbar, we've got no idea what manners of extensions or building options OP has. And for reference, opening the Tracemonkey PDF grows Firefox's RSS from 240 to 350MB. 3. The article's measurements includes rendered and cached pages, opening the TraceMonkey PDF grows my Firefox's RSS to 350MB but browsing to the end (and ensuring every page is loaded) ends up with a 480MB RSS, a behaviour which also exists (to a lower extent) on Preview, which grows from 44MB RSS to 85MB (then back down to 62MB) 4. Finally, the article specifically notes that "pdf.js still uses substantially more memory than native PDF viewers."
- rplnt 12y ago
  It does make sense when you look at it as a user. The result is the same.. requirements are not. With one you need a dedicated application, with other you need excessive amounts of memory. Also, there's about:memory available in firefox for quite detailed memory break-down.
  - masklinn 12y ago
    > It does make sense when you look at it as a user. No. You misunderstand point 1, I'm not saying comparing Firefox to Foxit as PDF viewers is nonsensical[0], I'm saying GP comparing the number he gets on his machine to the numbers provided by OP is not sensible: OP uses 64b Firefox on 64b OSX on an rMBP (the retina part quadrupling the size of the render target if software is compatible) while GP uses unknown bitness Foxit on unknown bitness Windows on unknown hardware. That's a fractally nonsensical comparison, just about everything which can be changed is changed. A somewhat real comparison would require that GP install a FF33 nightly on his machine and look at what happens there, and only looks at the difference between browser open and browser open + PDF. That would give the browser and PDF.js's overhead over opening PDFs in a native client. > Also, there's about:memory available in firefox for quite detailed memory break-down. Which is not what's in OP's graphs, not what GP compares his numbers to, and not relevant to my comment. [0] although it kind-of is, firefox bundles a PDF viewing utility for convenience, it's not a PDF viewer (unless you're in firefox os maybe?)

hbogert 12y ago

So.. the author is focusing on metrics - the memory usage. Basicly what's being done is release the caching sooner. Well what if a user's usecase scenario is such that he's looking at 2 pages after another a few times which have 10 pages in between.. This would cause a lot more rerenderings than before, making CPU go up. I'm not sure if I want to trade memory for CPU when running on battery

nnethercote 12y ago
Software is full of trade-offs. If slightly pessimizing an unusual case is the cost of drastically improving an extremely common case, then I'm happy to do that.
- pessimizer 12y ago
  Switching between two non-consecutive pages in a pdf is not an unusual case.
  - nnethercote 12y ago
    Switching by scrolling, or by jumping directly to the pages using a page selector? The latter case will be handled fine by a 10 page cache. Anyway, I think this fear is overblown. The CPU cost of rendering a single page isn't that high.

Pacabel 12y ago

This incident should serve as a very good lesson to those in the Firefox community who often claim that memory and performance problems don't exist, even after numerous users report experiencing such problems. Such memory and CPU consumption problems are often blamed on vague "third-party extensions", even when they happen with fresh installations on systems that have never before had Firefox installed. Or they're otherwise blamed on the user somehow, even when the user is engaging in a perfectly reasonable workflow. And even if the problems don't happen on one system, they very well could be happening on another system, as this very incident shows quite well. This part of the article is particularly relevant: "Shortly after that, while on a plane I tried pdf.js on my Mac laptop. I was horrified to find that memory usage was much higher than on the Linux desktop machine on which I had done my optimizations. The first document I measured made Firefox’s RSS (resident set size, a.k.a. physical memory usage) peak at over 1,000 MiB. The corresponding number on my Linux desktop had been 400 MiB!" This matches very well with what so many Firefox users describe as happening to them. The memory consumption ends up skyrocketing to well above what it reasonably should be. Gigabytes of memory are unjustifiably consumed. Perhaps now instead of ridiculing or ignoring people who report such issues, those in the Firefox community will perhaps do the responsible thing and take them seriously. It should be very obvious now that memory consumption problems can happen on one system, while not happening on another.

nnethercote 12y ago
Hi, Pacabel! Can you give specific examples of this ridicule? While I don't claim that everything is perfect, my experience is that for the past few years Mozilla has taken Firefox performance issues extremely seriously. For example, I started a project called MemShrink exactly three years ago to reduce Firefox's memory consumption. In fact, I even wrote a blog post today that discussed the major improvements from the past year, and what areas we still fall short on: https://blog.mozilla.org/nnethercote/2014/06/16/memshrinks-3rd-birthday/ https://blog.mozilla.org/nnethercote/2014/06/16/memshrinks-3.... And if you want more detail about this particular effort, you can read the 70+ status reports I've written in those three years here: https://wiki.mozilla.org/Performance/MemShrink https://wiki.mozilla.org/Performance/MemShrink. And since you mentions extensions, you could also read about how we solved the vast majority of the memory leaks that involved extensions here: https://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-plugs-the-add-on-leaks/ https://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-p.... That was almost two years ago. As for pdf.js, here's the bug I filed last year about it using too much memory: https://bugzilla.mozilla.org/show_bug.cgi?id=881974 https://bugzilla.mozilla.org/show_bug.cgi?id=881974. The title of the bug is "pdf.js uses too much memory". No ridicule or ignoring the problem there. MemShrink is just one of numerous performance-related projects that have been undertaken at Mozilla over the past few years. I'm sure with a little Googling you could find out about some of the others.

annnnd 12y ago

I don't want to sound negative and I certainly don't want to start a war here. I also really appreciate what Mozilla is doing and I am an otherwise happy user of FF on both desktop and mobile. That said, FF memory usage (not just pdf.js) is sometimes just insane. Granted, I only have 2GB on this Linux, but FF invariably eats most of it (with just 10-20 tabs) if left running for long periods. Interestingly enough, once I restart FF and reopen the same tabs, memory usage is far lower. Memory leak? Inefficient caching? Who knows... Every now and then there is a version of FF that claims to be using less memory, but in my experience the differences have been negligible. So as far I am concerned memory friendly FF is something like fast Java... I am still waiting to meet one of these beasts in the wild. :)

Gracana 12y ago
Is firefox actually using memory in such a way that other programs can't use it, or is it simply making efficient use of memory but caching everything it can?
- annnnd 12y ago
  VM starts swapping so much that it is not usable anymore.
  - Gracana 12y ago
    Ah, okay. By the way, I was just fiddling around and found "about:memory", which contains a lot of interesting information about memory usage and a couple tools for cleaning up memory. Might be interesting to look at when the browser starts bogging down your system.
    - annnnd 12y ago
      "about:memory" is probably great, but it is too detailed for someone who is not familiar with FF internal architecture. The way I see it it is mainly useful for FF developers. I like "about:addons-memory" (available if you install https://addons.mozilla.org/en-US/firefox/addon/about-addons-memory/ https://addons.mozilla.org/en-US/firefox/addon/about-addons-...).

pjc50 12y ago

Useful reminder: you can set "pdfjs.disabled" in about:config to turn it off and redirect PDFs to a native app of your choice. The concept of rendering PDFs in the browser isn't fundamentally bad, but large files crashing the browser is a disaster. This happened with Adobe as a plugin and it continues to happen. Now if someone can provide a means of un-embedding streaming video as well, that would be very useful.

fulafel 12y ago
This is pretty risky as native PDF readers are among the most targeted malware infection vectors. At least make sure you don't have Adobe Reader if you decide to risk this.
TheLoneWolfling 12y ago
> you can set "pdfjs.disabled" in about:config to turn it off Already do that. Bonus: I'm on a laptop intermittently without internet access, and can open up PDFs to read offline without having them be lost when my browser crashes. > Now if someone can provide a means of un-embedding streaming video as well, that would be very useful. Really hard to do, unfortunately. For HTML5 video, maybe (and I'd love it if someone came up with something of the sort), but for flash video the problem is that there isn't really any standard for flash video players, so you can't really parse the flash file to figure out what video to play without running it. That being said, maybe some sort of local proxy that recognizes when a video file is requested by flash and reports a 404 to it, with a popup "do you wish to open this link in a local player". But that way lies madness.
- ffreire 12y ago
  This could, perhaps, initially be implemented as a plugin that inspected/listened for link clicks and forwarded them to your application of choice. I believe VLC is capable of opening streams without too much hassle (not sure about other players). Sounds like a fun weekend project, at any rate!
  - TheLoneWolfling 12y ago

theblackswan 12y ago

this is good.

jeroen 12y ago

The current release is v1.0.68, v1.0.277 is a pre-release, so this will probably be in the next release or the one after that. ( https://github.com/mozilla/pdf.js/releases https://github.com/mozilla/pdf.js/releases ) I have recently switched my project from v0.8.1013 (from feb 2014) to v1.0.68 and rendering times have improved enormously. Good to see that there are more improvements coming.

_quasimodo 12y ago

I wonder if it is feasible to compress cached canvases, either as part of pdf.js or natively in firefox.

kuntau 12y ago

Maybe Chrome team should have this MemShrink meeting every once in a while. At the current state it will eat every memory available be it 8GB or 16GB system.