FlaxPDF pdf reader

[curaga]

I wrote a PDF reader over the extended weekend. flaxpdf.tcz is posted for 6.x x86.

Code: [Select]

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



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

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

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

[Juanito]

I'm not able to "Download the latest release" from the sf site with fifth, it downloads a 3kb file called "files"?

[Juanito]

flaxpdf posted to the x86_64 repo

[curaga]

Must've been some temporary SourceForge issue, the link works for me?

[coreplayer2]

FlaxPDF is awesome, highly functional and looks great too, I luv it
Thanks Curaga

[hiro]

I've improved scrolling for my use cases.
In particular I added j and k keys that scroll one view minus a couple lines like when you pgup/pgdown in opera. Also it's a bit more clever as when we're zoomed out enough j and k keys will align to the page like pgup/pgdown does.
I also fixed the pgup/pgdown buttons so that in page mode top margin isn't shown or bottom isn't cut off.
Hope you like it.

[curaga]

The behavior changes are fine, but there's some issues:
- crash when pressing page up or K on the first page
- the coding style is bad in places
- I don't understand why you divide MARGIN by the entire height in page up, did you mean to have parenthesis around floorf(yoff) + MARGIN?

I've applied the End hunk slightly edited, thanks.

[hiro]

I cannot reproduce the crash on page up, can you send me your test pdf? Does it happen right after starting the program without other preceding action?

I'll look into the other issues. I felt like there should be an easier way without converting from and to multiple relative and multiple scaled absolute units so many times, but all intuitive changes I made at first resulted in overshoot over margins or so

[curaga]

It happened on bitcoin.pdf: https://github.com/benjyz/bitcoinArchive/blob/master/bitcoin.pdf
First thing after startup, no other actions needed. Though it looks like a normal "0 - 1" bug, so it should happen in every pdf.

You may want to run under valgrind in case it doesn't crash for you - under dirty memory it may not segfault immediately.

And yeah, there should be helper functions for converting between the default page-relative coordinate system and screen/data pixels, just haven't had a sudden burst of motivation when it already works

edit: valgrind output confirms it's a 0-1 bug:

Code: [Select]

==16490== Invalid read of size 1
==16490==    at 0x40A175: pdfview::handle(int) (view.cpp:54)
==16490==    by 0x40DCA0: Fl::handle_(int, Fl_Window*) (in /tiedostot/mv/c/flaxpdf/src/flaxpdf)
==16490==    by 0x421F80: fl_handle(_XEvent const&) (in /tiedostot/mv/c/flaxpdf/src/flaxpdf)
==16490==    by 0x423CC6: do_queued_events() (in /tiedostot/mv/c/flaxpdf/src/flaxpdf)
==16490==    by 0x4240D6: fl_wait(double) (in /tiedostot/mv/c/flaxpdf/src/flaxpdf)
==16490==    by 0x40D421: Fl::wait(double) (in /tiedostot/mv/c/flaxpdf/src/flaxpdf)
==16490==    by 0x40D610: Fl::run() (in /tiedostot/mv/c/flaxpdf/src/flaxpdf)
==16490==    by 0x407C2C: main (in /tiedostot/mv/c/flaxpdf/src/flaxpdf)
==16490==  Address 0x28091e7c38 is not stack'd, malloc'd or (recently) free'd


[hiro]

Hey, here's my 2nd version, with new trust in myself I was able to simplify and it still works.
I hope the sanitization prevents any crashes now.

edit: use scroll-impr3.patch

[curaga]

Sorry, but that's still buggy. Asking for page 4294967295 doesn't produce a NULL pointer, it produces a very big pointer. The function shouldn't try to paper over invalid arguments in any case, the caller should not call it with wrong pages (which I see you added).

The new logic is good. I still have style quips, and as pgrel cannot return negative values, it should be an u32. Maybe call it screenpixels instead?
- a space on both sides of +, -, ==, !=, and other such math operators
- a space between if and (
- a space after a cast
- moving the zoomedh line is not needed

edit: Above was for scroll2.patch, but also applies to v3.