[Poppler-bugs] [Bug 56858] Huge simple PDF displayed blank in poppler-glib-demo

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=56858

--- Comment #5 from Adrian Johnson <ajohnson at redneon.com> ---
(In reply to comment #4)
> Is this performance issue inside the scope of poppler, or the API users
> (such as Okular) should implement render-by-demand by themselves using the
> available API?

It is possible for users of the glib API such as Evince to render smaller
areas. It is just a case of setting the clip area before rendering. But this
won't automatically make it render faster.

I did some testing with pdftocairo:

$ pdftocairo -png -r 72 Shimshon40.pdf out
rendering the full page (2591x19366 pixels) took 215 seconds

pdftocairo -png -r 72 -x 0 -y 0 -sz 2591 Shimshon40.pdf crop
rendering a 2591x2591 region (13% of the full page) took 144 seconds

Without having done any profiling I'm guessing the main reason the cropped
region took so long is the entire source image is scaled down instead finding
the region of the source image that corresponds to the cropped destination and
scaling that down.

There is no doubt plenty of opportunities for optimization. But given that PDFs
this size are uncommon it is not a high priority for me. But if you have more
huge PDFs I'm happy to include them in any testing and profiling I would do to
improve the performance of the cairo backend.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20121112/721c409e/attachment-0001.html>