Tiny Core Extensions > TCE News
FlaxPDF pdf reader
curaga:
I wrote a PDF reader over the extended weekend. flaxpdf.tcz is posted for 6.x x86.
--- Code: ---FlaxPDF is a fast, nice multithreaded PDF viewer for the desktop.
As long as there are more pages than cores, every core will get a workout.
Light on dependencies, trimming borders, and aggressive caching are
its major points. Okular and Evince are nice but heavy; and the point
for starting this project, ePDFview, is dead.
EPDFview was nice and light, but lacking in a couple ways:
- no caching, if you wanted to backtrack one page, it reloaded slowly
- no automatic zoom to content/trim
Now with my main PDF viewer being dead, why not build a fresh one with
those two itches scratched?
Requirements
------------
Poppler, LZO, and FLTK 1.3.
Comparison
----------
Evince 3.10.3, FlaxPDF 0.6.1 and ePDFview 0.1.8 were tested. The same
document was scrolled repeatedly to check the cpu usage, the binary size
was measured, as well as RAM use.
CPU RAM Binary
Evince 90% 56.8 MB 507 KB (evince + libpdfdocument.so)
ePDFView 72% 46.3 MB 124 KB
FlaxPDF 57% (5% *) 36.5 MB 45 KB
* To be fair to all, these measurements were done using the Vesa driver.
FlaxPDF, as the only one of the three, is able to take advantage of the GPU,
dropping its CPU use when scrolling to 5% (tested on radeon).
--- End code ---
The site is still being designed, but flaxpdf.sf.net will be the location when done.
I should note that the old XVesa cannot run this, but Xorg and the newer TinyX servers can. (Which reminds me, I really should get the tinyX builds done - currently only x86_64 Xfbdev is the new one, x86 is still shipping both old ones...)
Being an aggressively caching reader, it is not suitable for very low-RAM systems, depending a lot on the document used. Text-only documents don't use much RAM, but picture-heavy ones may easily use over 100MB.
hiro:
very nice.
bug: canceling the file dialog triggers quit.
finally a pdf reader that uses my CPU :D
moving to page 540 of 5432 in one of my pdfs took ages.
i guess pages are rendered in sequence and for this usecase to get faster there would need to be some kind of scheduling that takes into account where we are and renders the pages around that position first.
this is with a 36MB pdf, right now VSZ is showing 1.2GB and flax is still rendering more pages :)
curaga:
5400 pages :o
Sounds like a lot of images too, or scanned text (=images).
The pages are actually rendered in random order, decided by OpenMP.
curaga:
Posted 0.7 that allows skipping around while big documents load.
hiro:
Awesome! Now I can read OMAP4430_ES2.x_PUBLIC_TRM_vO.pdf faster than anyone else (pgdown).
And since it's winter here I'm fine with the comfortable excess heat :)
Navigation
[0] Message Index
[#] Next page
Go to full version