5 ms·

Great idea and props for shipping. There's something extremely wrong with your implementation as it just takes too much to render every page. I've done plenty

Great idea and props for shipping. There's something extremely wrong with your implementation as it just takes too much to render every page. I've done plenty of work in the past with both canvas and pdf.js (which is what you're using) and it shouldn't be that slow, at all. Perhaps you have a rogue loop that's calling a very expensive function on each pixel of every page, maybe? Who knows, but for sure performance on that could be near real-time.

seedgou 5y ago
I didn't manipulate the data in pixel level. Maybe because I render PDF in 2x which causes 4x more pixels?
- moralestapia 5y ago
  That could be the case yes, still I feel it should be better, let me do a quick test as I have some spare time.
  - seedgou 5y ago
    The rendering logic is in `src/utils/pdf/renderPage.ts` and has only 26 lines.
  - moralestapia 5y ago
    Here's a very naive blur implementation (which is your most expensive operation there), https://codepen.io/almosnow/pen/abEXBZP?editors=0011 https://codepen.io/almosnow/pen/abEXBZP?editors=0011 (at the end of the blur pass it prints the elapsed time to the console) You're right, it does get kind of slow at 2x, but not that slow, on my laptop it takes around 1 sec/page, while on your site takes 20-30 secs/page. Also, my very naive code does not take into account "warming up" and some other code optimizations to make the blur much faster, you could easily get it down to 100ms/page, I'm sure! Best luck!
    - seedgou 5y ago
      Oh! You mean the scanning speed. I thought you was talking about the original PDF preview. For now, scanning is using emscriptened ImageMagick Wasm. Due to the translation from C++ to Wasm, the scanning speed is very slow. Maybe re-writing blur, rotate and noise algorithm will speed up the scanning.
      - hobo_mark 5y ago
        Ah, wasm... The site managed to almost kill my machine until the tab committed OOM suicide, I guess this explains why.
- zikohh 5y ago
  yeah even playing with the preview and using the sliders it's super slow apart from that it's amazing! Do some work on the perf pls.
  - obeattie 5y ago
    You are right about performance, but does it really matter? It feels like this is the sort of tool one needs (very) infrequently, and those cases don’t seem like the sort of thing where seconds really matter. I think it’s plenty good enough. I prefer to focus on how grateful I am that the author has made this and published it for free.
    - moralestapia 5y ago
      I believe it does matter. When one first opens the site and nothing happens for 30 secs. you assume that the pdf you're looking at is the actual result (that happened to me, at least), then the other one pops up and you're like ... ooooh I get it! Most users wouldn't be as patient and just leave.
redman25 5y ago
I wrote a similar program using PDF.js that renders near real-time (https://parepdf.com https://parepdf.com). You should be able to queue it up without too much trouble. If you’re doing pixel level manipulation, you want to make sure you’re finishing within the browsers frame budget.

seedgou 5y ago

I didn't manipulate the data in pixel level. Maybe because I render PDF in 2x which causes 4x more pixels?

moralestapia 5y ago
That could be the case yes, still I feel it should be better, let me do a quick test as I have some spare time.
- seedgou 5y ago
  The rendering logic is in `src/utils/pdf/renderPage.ts` and has only 26 lines.
- moralestapia 5y ago
  Here's a very naive blur implementation (which is your most expensive operation there), https://codepen.io/almosnow/pen/abEXBZP?editors=0011 https://codepen.io/almosnow/pen/abEXBZP?editors=0011 (at the end of the blur pass it prints the elapsed time to the console) You're right, it does get kind of slow at 2x, but not that slow, on my laptop it takes around 1 sec/page, while on your site takes 20-30 secs/page. Also, my very naive code does not take into account "warming up" and some other code optimizations to make the blur much faster, you could easily get it down to 100ms/page, I'm sure! Best luck!
  - seedgou 5y ago
    Oh! You mean the scanning speed. I thought you was talking about the original PDF preview. For now, scanning is using emscriptened ImageMagick Wasm. Due to the translation from C++ to Wasm, the scanning speed is very slow. Maybe re-writing blur, rotate and noise algorithm will speed up the scanning.
    - hobo_mark 5y ago
      Ah, wasm... The site managed to almost kill my machine until the tab committed OOM suicide, I guess this explains why.
zikohh 5y ago
yeah even playing with the preview and using the sliders it's super slow apart from that it's amazing! Do some work on the perf pls.
- obeattie 5y ago
  You are right about performance, but does it really matter? It feels like this is the sort of tool one needs (very) infrequently, and those cases don’t seem like the sort of thing where seconds really matter. I think it’s plenty good enough. I prefer to focus on how grateful I am that the author has made this and published it for free.
  - moralestapia 5y ago
    I believe it does matter. When one first opens the site and nothing happens for 30 secs. you assume that the pdf you're looking at is the actual result (that happened to me, at least), then the other one pops up and you're like ... ooooh I get it! Most users wouldn't be as patient and just leave.

redman25 5y ago

I wrote a similar program using PDF.js that renders near real-time (https://parepdf.com https://parepdf.com). You should be able to queue it up without too much trouble. If you’re doing pixel level manipulation, you want to make sure you’re finishing within the browsers frame budget.