https://bugs.kde.org/show_bug.cgi?id=177213
--- Comment #15 from Mark Whitis <whitis freelabs com> 2009-05-25 08:29:17 --- I can certainly appreciate that X pixmap storage on the server could significantly improve performance in many cases. Indeed, okular seemed a bit faster than evince at first, which was largely why a switched. But in the long range memory consumption ultimately causes it, and the rest of the system, to be slower. This would not be the case on a system with ample ram. And the sharing pixmap cache feature, if it actually exists, or an equivalent mechanism with the same effect would be a very good thing in terms of keeping the ram cache reasonable by caching just the document the user is currently paging through. And I care about the performance because I skim documents at very high speed to find what is relevant. Often as fast as the viewer can rasterize the pages. I regularly use huge documents, often many at the same time. Albert: having a (non-hidden) setting to disable pixmap cache on the server could help, in the situations it is needed for. You would simply reuse one or two pixmaps to render either the visible area or the page or two that occupies it. Since only one or two pages would be cached on the server, each instance would use little memory there. If you have 10 instances, you only have 10 or 20 pages stored on the server (still a lot if you use 24bit mode) If that pixmap doesn't get freed, it takes a lot longer for the system to become unstable. You reuse those pixmaps. But this ends up being very close to just setting cache_size=2, if the cache is made of non-sharable pixmaps. I.E. the degeneration case of the cache would more or less do what you would do if you weren't caching. The real minimum X server memory usage case is when you bitblt the bottom portion of the top page and the top portion of the bottom page (assuming a typical case where part of two pages is visable) from a client side pixmap directly to the framebuffer and scroll by using a bitblt to move the memory up (or down) and then a small bitblt to fill in the missing piece. Things get more complicated, though, when part of the window is obscured. And applications sometimes have subtle errors in the update code. Or you can bitblt into the back buffer, then let X copy to the window. Easier because you don't have to worry about obscuring windows (which may even move on you) in either the draw or the scroll operations. But it may be easier, and ultimately more beneficial, to carefully check for bugs in the cache handling than to write new code which could result in the old set of bugs plus a new set. The statement that okular reduces its cache use based on available system memory might explain why the usage caps at 160MB on my machine. Yet free memory is a nebulous concept on a system which uses virtual memory and fills any unused memory with disk buffers. And there is the timing of exactly when this reduction of cache occurs. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
