OSNews > Thread > "RE[2]: Overstated conclusion" by Soulbender

Cairo, Xlib, and the Shared Memory Extension

Linked by Thom Holwerda on Sat 28th Jun 2008 22:09 UTC, submitted by diegocg

"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."

1 42 Comment(s)

http://osne.ws/fdr

Thread beginning with comment 320564
To view parent comment, click here.
To read all comments associated with this story, please click here.

RE[2]: Overstated conclusion

by Soulbender on Sun 29th Jun 2008 12:07 UTC in reply to "RE: Overstated conclusion"

Member since:
2005-08-18

Move back to 10baseT or 10base2 and compare it's performance

True but we're in 2008 now, not 1990, and no one is using 10baset and 10base2 anymore.
If you do, well, get with the program.

Reply Parent Bookmark Score: 5

RE[3]: Overstated conclusion

by sbergman27 on Sun 29th Jun 2008 17:19 in reply to "RE[2]: Overstated conclusion"

Member since:
2005-07-24

True but we're in 2008 now, not 1990,

Actually, I did not directly address this issue in my previous response to tyrione. X works about as well under 10baseT as 100baseT. People have a tendency to think in terms of bandwidth. X actually does quite well over limited bandwidth. It is latency which kills the standard (non-NX) X protocols. 10baseT has essentially the same latency as 100baseT. The most dramatic way to demonstrate standard X's sensitivity latency is to set up a ppp connection over an external modem. Start an application like Firefox and watch the lights. According to, I believe, Keith Packard some years ago (who had worked on LBX previously), approximately 90% of the round trips were actually unnecessary and an artifact of the then current implementation, and not inherent in the protocol itself. He was working on eliminating those unnecessary round trips. Not sure where we stand today.

However, it does not really matter, because for any sort of WAN connection we have NX.

Edited 2008-06-29 17:26 UTC

Reply Parent Bookmark Score: 3

RE[4]: Overstated conclusion

by Soulbender on Sun 29th Jun 2008 17:42 in reply to "RE[3]: Overstated conclusion"

Member since:
2005-08-18

10baseT has essentially the same latency as 100baseT.

I thought his point was the 10baseX saturates quicker, given X being more bandwidth hungry, thus causing higher latency.

Reply Parent Bookmark Score: 3