How to disable/limit pixmap cache in X

[Carsten Haitzler (The Rasterman)]

On Wed, 19 Sep 2007 17:08:22 +0100 Gavin McCullagh <gmccullagh at gmail.com>
babbled:

> Hi (and apologies for breaking thread),
> 
> Glynn Clements wrote 
> 
> > The server doesn't "cache" pixmaps, it stores them.
> > 
> > [The server may cache some of those pixmaps in video RAM, with the rest
> > stored in the server's memory, but this isn't visible to the client.]
> > 
> > A "cache" duplicates information which is available elsewhere in order to
> > improve performance. The term implies that the cached data can be
> > discarded at will, with the only consequence being increased "cost" if
> > the data is required later.
> 
> I guess Jim's use of the term "caching" is from the perspective of firefox
> -- in that firefox still has access to the compressed image files and can
> at increased cost, re-create the pixmaps.
> 
> It would seem that Firefox (or rather Gecko) leaves the images in the video
> ram, whereas others such as Konqueror and Opera do not.  This would
> certainly seem to be a Gecko bug.  It is being worked on, at least in some
> sense
> 
> 	https://bugzilla.mozilla.org/show_bug.cgi?id=296818
> 
> though to be honest, having a timeout seems like turning a bug into a race.
> 
> > A pixmap is an image which is stored by the server. If a client tells the
> > server to create a pixmap, failure to do so is likely to be considered a
> > "fatal" error by the client. Once the server has created a pixmap, it is
> > required to store it until the client explicitly tells the server to free
> > it.
> 
> I'm not an expert in X, so please excuse (and feel free to correct) me if I
> have read this situation wrong.  In the same sense as a web client should
> never be able to crash a web server, surely an X client should not be able
> to crash an X server?  I would have thought for the sake of the X server
> and its user, it should be able to prevent a client from using arbitrary
> amounts of memory.  Perhaps this is my idealistic or even wrong point of
> view?

correct - but you didn't account for linux's default mdoe of optimistic
allocation and mr. OOM killer. linux will return memory regions even if there
is not enough to survive the request - assuming you don't actually use it all.
you can tune this off and it should begin to help- then when you are out of
memory you actually get a NULL back from malloc etc. and then - if the code is
good, it can handle the null return and "unwind" safely. the problem is the
over-allocation by default that makes any attempt to handle NULL properly a
moot point.

> It probably would be a fatal error for the client, but that's okay.  I'd
> rather the client crash than the server.  Clients can then be fixed to
> react nicely if creation of a pixmap gets refused.  
> 
> > If an application makes "excessive" use of pixmaps, this has to be dealt
> > with in the client.
> 
> I agree, except that one cannot chase every rogue application down to
> ensure stability of the X server.
> 
> > > It appears that the ability to cache pixmaps to RAM is not a necessity
> > > and rather a feature to help speed up image access.
> > 
> > Yes and no.
> > 
> > The client could store the image itself (as an XImage), and send the
> > image data to the server whenever it wants the image to be drawn.
> > However, this is the client's decision; if the client decides to store
> > the image in the server (as a pixmap), the server doesn't really have
> > much choice in the matter.
> 
> Is this fundamental to how X servers and clients interact?  Is it really
> not feasible for the server to refuse, in order to preserve itself and the
> other running applications?

nb - storing them in client memory and using ximages as a delivery mechanism
for drawing as opposed to pixmaps will MASSIVELY increase your network
bandwidth usage and slow things down a lot. pximaps live in the xserver - and
if possible in video ram. this means theory are fast to access, only need to
be generated/uploaded when first "created" or modified, not on every redraw of
the window.

> Gavin
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)