
"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."
Member since:
2005-07-06
This is a key point!
The "idiocy" comment in the original posting was way off-base. The XImage system actually makes a ton of sense. In most apps, you're drawing the same images over and over again (sprites, chrome). Its not a big deal to transfer them to the X server the first time they're drawn. In a web-browser context, you're drawing different images all the time, but what do you think is the bottleneck, copying the image to the X server, or downloading them from the internet?
Where XShm helps is when you dynamically generate images for each frame, and as such are constantly uploading new images to the Xserver to draw. However, even in that case, it is unlikely to provide a huge speedup, since the overall time is probably dominated by creating the image, not copying it to the X server.