[poppler] pdf rendering performance on the olpc test boards

[Krzysztof Kowalczyk]

On 11/7/06, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> Yes, tried with --enable-fixedpoint --disable-cairo-output
> --enable-splash-output and although the profiling changes a lot it is
> still similarly slow.

I tested your pdf on an a device using arm processor that, I would
think, is slower than geode (at least in pure MhZ) and a page renders
in about 2 seconds (using very unscientific method - I could get more
precise timings) so a 4s rendering time is surprising. I use splash
backend and not even using fixed point.

If you post profiling results somewhere, for both cairo and splash
cases, I can take a look, although not being able to play with it,
chances of finding a magic switch to make go things faster are slim.

In my app I render the pages in a background thread to improve
perceived responsivness of an app and I think it helps usability a
lot.

On a related note, if you're willing to spend some more engineering
time, you can take a look at Fitz/MuPDF
(http://ccxvii.net/apparition/). The code quality is better than
poppler's (it checks for and handles memory allocation failures which
is not the case for poppler and is important on an embedded device).
About a year ago I built a prototype PDF viewer based on this code and
it looked like a complete implementation of PDF. I didn't end up using
it and went with poppler instead because at the time mupdf had a weird
ghostscript-like license (it's written by one of the ghostscript
people) but recently it switched to pure GPL so I'm reconsidering. The
downside is that there is no evolved viewer using this code (a basic,
cross-platform viewer is part of mupdf code, but it's very limited in
features).

I haven't done any perf comparison but I'm hoping that mupdf will be
faster because poppler's parsing and i/o is slow and it's not easily
fixable.

-- kjk | http://blog.kowalczyk.info/software/sumatrapdf/