Why not have X-Windows store the COMPRESSED image?
Posted Jun 29, 2006 20:50 UTC (Thu) by
oak (subscriber, #2786)
In reply to:
Why not have X-Windows store the COMPRESSED image? by kleptog
Parent article:
Interview: Jim Gettys (Part I)
> Personally I think more use should be made of the XShm extension,
> when the client stores the images in shared memory and the X server
> can see them. One thing graphics processors can do is blit images
> and convert colour and layout on the fly.
The X client memory is main RAM on the machine, X server memory
is (partly) memory on the graphics card. I.e. at least the graphics
needs to be copied from the client SHM memory to the gfx card memory
before blitting on screen. However, I don't think this is an issue
compared to the issue of app keeping images redundantly in memory and
making the whole machine swap...
Probably one reason why apps store so much images to the X server
is that this way the images can be blit much faster when the app
is using X server remotely. Faster networks make copying image data
from the remote client to X server less of an issue but maybe with
server side images there's less latency? (which is the real killer
of UI responsiveness with remote X)
> I think what would really help is a way to see what pixmaps
> (and other resources) are currently stored in the server.
> That would make it easier to see if anything is being leaked.
There is already a such thing. There's a patch to the X resource
extension and simple utility for showing the listed pixmaps.
It was mentioned in one of the optimization blogs I think.
Btw. For measuring application response times (e.g. to see whether
performance optimization had an effect), there's a tool called
"xresponse" (it outputs timestamped "X damage" i.e. screen updates
events).
(
Log in to post comments)
