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 320558
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Caching?
by gilboa on Sun 29th Jun 2008 09:11 UTC in reply to "Caching?"
Member since:

Why not cache a few larger XShm segments and parcel out pieces of them for small images? That would save a lot of the setup costs.

I wondered the same. (I have zero experience with xlib; I'm just guessing)

In general you can do one of two things:
A. Create slab cache management for Shm (within xlib; E.g. 1KB, 2KB, 8KB, 16Kb). Use lazy release for unused blocks.
B. Allocate a huge shared buffer and cut it into small random-size pieces.

(B.) has the obvious down side of concurrency that may negate any performance advantage you get by reducing the number of share memory blocks to 1.
(A.) will increase the memory footprint of your application and fragment your memory. (Especially in browsers - where image size tend to vary radically)

- Gilboa

Reply Parent Score: 3