OpenOffice client freeze on print figured out (and other app freezes)

[Jim Kronebusch]

> As for your comment about thinking this is an Xorg problem.  I sort of 
> agree/disagree.
> 
> I think it's a problem in the interface BETWEEN the Xserver and the 
> Xclients.
> 
> The Xserver needs to be able to refuse requests for pixmap allocation, 
> and the Xclients need to pay attention to that refusal and gracefully 
> handle it.   Right now, we are limiting pixmap allocation by setting 
> X_RAMPERC.  the problem is, the Xclients die a horrible death when they 
> don't get what they want from the Xserver.

Let me try and get a little better understanding here (forgive me if what I ask doesn't
make sense).  It seems that if pixmap caching to system memory was restricted
specifically the applications would maybe still run upon refusal of a pixmap cache
request, but have more of a delay in displaying the graphic when called on.  However the
X_RAMPERC option limits the application to use of RAM in general and when it hits the
limit it then dies a horrible death.  So if there was some method to split these two
apart things may behave in a more tolerable fashion?  Would Firefox still then be free
to hog as much RAM and SWAP as it could get it's grubby hands on for basic operation but
then be told by some new option to back off on the caching of pixmaps, or are the two
inseparable?  It seems that most every scenario where the clients are freezing in most
every application are due solely to excessive pixmap caching either by a single app or a
combination of apps used simultaneously.

Is it conceivable that an option could be available in xorg.conf that limited pixmap
caching to 32MB max (user configurable to increase/decrease as desired), or maybe have
an option in lts.conf to pass this to X but still leave memory use unrestricted for
everything but pixmaps? (lts.conf stuff would of course start with X having this
capability)  This may be the route I try to take when I start posting to the xorg devel
list.  Of course they may very accurately respond telling me I'm crazy.

Another thing I played with today when monitoring pixmap cache from within OpenOffice,
insert a handful of graphics into a Writer document, open xrestop to monitor usage, then
scroll back and forth over the the graphics and watch pixmap cache climb.  I was able to
insert 4 images into Writer and only consume 8MB of cache with pixmaps, but upon
repetitive scrolling and no other changes increase Writers pixmap cache to 155MB. 
Something this stupid would be enough to freeze a client with 128MB RAM (silly thing to
do but I am amazed everyday at the stupid things people do).  I find it odd that Writer
doesn't just cache the image once and then draw from it, it keeps caching the same info
over and over again....seems like just bad programming to me.  So if there was a setting
to limit only pixmap caching we could still see a performance increase at first, but
then if an application got greedy or just plain stupid, it would get cut off, but still
be allow full use of RAM and SWAP to keep critical processes running.

Thoughts?

-- 
This message has been scanned for viruses and
dangerous content by the Cotter Technology 
Department, and is believed to be clean.