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 useless. 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. Regards -- Sebastian Ramacher
Description: Digital signature
_______________________________________________ zathura mailing list firstname.lastname@example.org http://lists.pwmt.org/mailman/listinfo/zathura