[poppler] pdf rendering performance on the olpc test boards

[Tomeu Vizoso]

On Tue, 2006-11-07 at 12:33 -0800, Krzysztof Kowalczyk wrote:
> 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.

Have to correct myself, due to some linking problem I still don't
understand, I wasn't using the splash backend when I thought I was.

After managing to use splash, it has much better performance, approx. 1
second of "Loading" message before appears the content.

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

I will send you a cairo profiling that hope makes some sense.

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

Yes, we use evince that does something like this.

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

We are having more problems with rendering, but I think it has to do
with our still slow graphics capabilities.

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