On 2013-03-25 04:14:25, Marwan Tanager wrote:
> > Also, I remember, that I hit a mem-leak recently when working on a
> > poster made with LaTeX. I was recompiling the same page over and over
> > again with LaTeX and I the memory consumption went very high. I was
> > wondering if this is because zathura was remembering the pages from the
> > previous versions of the recompiled document. Maybe zathura should free
> > memory on document reloads?
> Yes, this is an actual bug that is reported at http://bugs.pwmt.org/issue274 
> and it should be fixed. Maybe you're the one who reported it!

Everything except the file monitor and the zathura_t instance should be released
and re-created (if I remember that correctly), i.e. the document gets closed and
re-opened again. zathura is just a PITA to run with valgrind. There are so many
GTK related errors, that we can't fix, that valgrind's output is pretty much

We might have missed a free, g_object_unref, etc. somewhere of course. So
ideas to find memory leaks without valgrind or a use-able suppression file for
valgrind are very welcome.

> > Also, I thought a while ago, that zathura's rendering experience could
> > be even further enhanced by caching the pages, which have not been seen
> > yet. For example at one moment we see a row of pages and zathura caches
> > the row above and below the one we currently view. Then if we scroll in
> > either direction, the page is already rendered, which might be visually
> > more pleasing than waiting for a large page to come up. Of course, this
> > should be implemented in such a way, that we do not recache the pages,
> > which are already among the ones which have been looked at recently.
> That's exactly what I've just been thinking about, simply a sliding window of 
> a 
> configurable number of rows centered at the current visible one and moving 
> with 
> us as we scroll around.
> Combined with the above caching, then pages outside of this window shouldn't 
> be 
> freed unless they 1) aren't in the cache, or 2) are in the cache, but need to 
> be invalidated in order to make room for the currently visible ones if they 
> aren't already in the cache.

That'd be nice to have. Instead of a configurable number of rows we'd need
something that also loads pages left and right of the current page if
pages-per-row is larger than 1.

Sebastian Ramacher

Attachment: signature.asc
Description: Digital signature

zathura mailing list

Reply via email to