Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!sgi!shinobu!odin!sgihub!dragon!sgi.com!karlton
From: karlton@sgi.com (Phil Karlton)
Newsgroups: comp.sys.sgi
Subject: Re: X11 Optimizations?
Message-ID: <1990Nov8.022904.9366@relay.wpd.sgi.com>
Date: 8 Nov 90 02:29:04 GMT
References: <9010311759.AA18802@noname> <1990Nov2.084053@msc.EDU>
Sender: news@relay.wpd.sgi.com ( CNews Account )
Reply-To: karlton@sgi.com
Organization: Silicon Graphics, System Software Division
Lines: 26

In article <1990Nov2.084053@msc.EDU>, ken@msc.EDU (Ken Chin-Purcell) writes:
|> A shared memory connection can give a performance kick when
|> transffering a lot of data, such as with an XPutImage or XGetImage
|> call.

Using shared memory for general X transport (as opposed to specific for images) makes the most difference in a System V implementation without UNIX domain sockets or a slow TCP/IP loopback. SGI doesn't suffer from either of those problems.

|> To optimize these calls the noble MIT programmers wrote an
|> unofficial server extension to implement shared memory image
|> transfers.  Using the extension, you (the X window client programmer)
|> place the image data in a shared memory segment before calling
|> XShmPutImage or XShmGetImage.  The request goes through the normal
|> socket channels, but the image data skips the slow road.

The MIT-SHM extension is implemented in a future release.

|> To SGI: X windows is important to me, and I'm looking forward to a faster
|> server.  I would like a level of integration between X and gl where I
|> could render in gl but have window configuration handled by X.  I am
|> only using X for the user interface toolkits; I don't need to mix X
|> and gl graphics in the same window.

You should be happy with that unnamed future release.

I speak for myself, and not SGI.
PK