[Okular-devel] [Bug 177213] High X server memory consumption

[Mark Whitis]

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.