[texworks] Wishlist for pdf previewer

Charlie Sharpsteen chuck at sharpsteen.net
Mon Sep 26 02:34:16 CEST 2011


On Sun, Sep 25, 2011 at 4:31 PM, Charlie Sharpsteen <chuck at sharpsteen.net>wrote:

> The amount of memory the new viewer consumes at high zoom levels is
> pretty appalling---it will eat gigabytes once the zoom level gets over
> 1000%. We'll need to figure out how to cut this down via smart caching of
> pixmaps and perhaps tiling out the page renders at high zoom. Splash didn't
> seem to be capable of partial page renders as it renders the whole page and
> then crops the result.
>
> If Cairo can do a partial pages, it would make a very strong argument for
> using it as our render backend.
>
> -Charlie
>

Bad news on the partial render front---looks like Poppler just can't do
it---at least not in an efficient manner. Every page render request,
regardless of the backend that is used, causes Poppler to re-parse the
entire page rather than parsing once and then working off of some sort of
cache. The parsing requires the most time and processor power so splitting a
large pixmap up into tiles basically multiplies the rendering time by the
number of tiles that are used.

Discussions and bug reports in other projects:

   - Evince: https://bugzilla.gnome.org/show_bug.cgi?id=303365
   - Okular: https://bugs.kde.org/show_bug.cgi?id=148527

I think Okular's method of dealing with the problem makes the best of a bad
situation--once the amount of pixels in a rendering request exceeds a
certain value, they just ignore it. So the user can zoom in as much as they
like, but after a point things just stay fuzzy. This would be pretty easy to
implement in our current rendering setup.


If only there was an open source PDF library that provided threadsafe
partial rendering...

-Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110925/460d1d61/attachment-0001.html>


More information about the texworks mailing list