Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Shared Memory Connection
Message-ID: <9005021314.AA11466@expire.lcs.mit.edu>
Date: 2 May 90 13:14:53 GMT
References: <1990May1.233911.639@caen.engin.umich.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 19


    Our Stardent GS 1000 (Stellar GS 1000) uses shared memory and we have a 
    flipbook image which uses GetImage and PutImage to flip over 200 half
    megabyte images per second.  Try that with sockets.

This example is not to the main point.  In R4 we have an experimental
extension which uses shared memory for GetImage and PutImage; it doesn't
require a full shared-memory transport to deal with these requests, and
in fact it is more appropriate to special-case these requests.  In a
normal transport, even when it's shared-memory, the PutImage request
still has to copy from the "source" into the shared-memory transport
buffer, which is an expensive operation.  Better to just put the image
itself in shared memory, and send a pointer to it, which is what our
extension does.

I think the question more directly was, excepting image data transfer,
does the use of a shared memory transport buy you significant performance
for the core X protocol over other local transports?  In our (limited)
experience, it buys little.