Linked by Thom Holwerda on Sat 28th Jun 2008 22:09 UTC, submitted by diegocg
X11, Window Managers "Maybe I'm just naive, but designing a graphics API such that all image data had to be sent over a socket to another process every time the image needed to be drawn seems like complete idiocy. Unfortunately, that is precisely what the X Window System forces a program to do, and exactly what Cairo does when drawing images in Linux - a full copy of the image data, send to another process, no less, every time it is drawn. One would think there would be some room for improvement. Unsurprisingly, others felt the same way about X, and decided to write an extension, Xlib Shm or XShm for short, that allows images to placed in a shared memory segment from which the X server reads which allows the program to avoid the memory copy. GTK already makes use of the XShm extension, and it seems like a good idea to see if Gecko couldn't do the same."
Thread beginning with comment 320596
To read all comments associated with this story, please click here.
Comment by SomeGuy
by SomeGuy on Sun 29th Jun 2008 17:58 UTC
Member since:

Sockets are essentially a memcpy() in kernel. They're quite cheap when amortized over blitting the same image to screen repeatedly

Shm leads to hard synchronization issues, which could lead to messy pixmap stomping if the client/X server isn't careful.

But more importantly, the SHM data *must* be kept in the shared buffer. This doesn't sound so important until you realize that the image *doesn't* want to live in the shared buffer when it's being accelerated. what does this mean?

Well, if you're using the shm extension, you're essentially forcing the X server to draw in software (not that it's a change from the poorly accelerated proprietary drivers he was using, anyways.)

If you upload images and paint them repeatedly, the good old upload-over-a-socket allows X to put the pixmaps wherever it wants to get best performance. This is really why XSHM is discouraged these days.

Reply Score: 4

RE: Comment by SomeGuy
by renox on Sun 29th Jun 2008 20:23 in reply to "Comment by SomeGuy"
renox Member since:

I don't understand your point about the shared memory preventing hardware optimisation: all the extension says in that in the end the one who create the data must put it at this 'shared memory' location?

If the GPU can read or write at this memory location (depending on the operation of course), why couldn't there be hardware accelation?

Reply Parent Score: 2

RE[2]: Comment by SomeGuy
by SomeGuy on Sun 29th Jun 2008 21:13 in reply to "RE: Comment by SomeGuy"
SomeGuy Member since:

Because if you can't move the pixmap to fast video ram for accelerated hardware operations, you've already lost. Although just using XShmPutImage can sometimes be a win, it isn't always, because chances are you'll be copying or moving the memory anyways.

The X SHM extension -- the way it's normally used -- makes it very hard to do this efficiently, if not entirely impossible, so Xshm beats traditional XPutImage if you only care about a single blit, but if you're reusing the pixmap it can be a net loss, depending on your drivers (the better the drivers, the more of a loss it is)

In fact, it's so much worse that Exa (the new Xorg acceleration architecture) actually disables parts of the extension (shared pixmaps) so that it can properly accelerate 2d stuff.

Reply Parent Score: 2