
There is no easy answer to this question: it depends on whether the display
device can hold pixmaps in off-screen memory, and if so, how efficiently
the server manages these resources (having to deal with limited off-screen
memory is the bane of the server implementor's existence!).  

I have worked with graphics devices where the off-screen memory to 
main display copy rate eclipses that of the main memory to display copy
rate, and with those where the main memory to display is *faster* than
off-screen to display (requires only a write to the framebuffer rather
than a read of the F.B. followed by a write)

If your server uses the cfb code or something like it to render into
pixmaps in CPU main memory, the rates you can get through MIT-SHM are
likely to be equal (maybe a tad slower, depending on your OS's implementation
of shared memory) to CopyArea from pixmap to window, which is also then
just a copy from CPU main memory to graphics device.

One advanage of MIT-SHM is that if your images are large, you don't end up
growing the size of the server process to hold them.

One disadvantage of the MIT-SHM is that, in its sample implementation,
there is no provision for elegantly cleaning up the shared memory segments
if the client dies a sudden, violent death (e.g., "kill").  You have to 
be mindful of cluttering up the system with zombie shared memory segments.

	Ken