[comp.windows.x] Short circuiting network communication

posdamer@cbnewsm.att.com (jeffrey.l.posdamer) (12/06/90)

We are using X11R4 to write some application software.  Two problems have arisen
that I need pointers to solutions.

(1) When server and client are resident on the same machine, is there a 
reasonable way to NOT pass messages over the net, but directly (e.g. memory-
-to-memory ??) to enhance performance ?  

(2) We are using 256 colors in specific windows. In several window managers
that we have tried, when the cursor leaves the color window, the window goes
black.  We assume this is due to color table swapping. Is there a wm that
provides a mechanism for avoiding this ?

Apologies if these are 'obvious' or overly 'common' questions. I'm not
a frequenter of the X world.

Please respond to:

	jeffrey.l.posdamer@att.com

If there is wider interest, then let's chat it up on the net.

Many thenks, jlp

mouse@LARRY.MCRCIM.MCGILL.EDU (12/10/90)

> We are using X11R4 to write some application software.  Two problems
> have arisen that I need pointers to solutions.

> (1) When server and client are resident on the same machine, is there
>     a reasonable way to NOT pass messages over the net, but directly
>     (e.g. memory-to-memory ??) to enhance performance ?

The MIT-SHM extension does this, but (as I understand it) only for
pixmaps.  (Of course, images are typically the largest things to be
shipped back and forth over the communication channel.)

It probably would not be hard to build a server and a matching version
of Xlib that speak via a shared memory segment.  If you can come up
with a way to layer a reliable byte-stream interface on top of the
shared memory (not difficult), that's all you need....

I have a very hazy memory that someone may have done this.  I have no
idea who, or the status of the resulting code; I'm not even sure the
memory isn't just an amalgam of other things.

> (2) We are using 256 colors in specific windows.  In several window
>     managers that we have tried, when the cursor leaves the color
>     window, the window goes black.  We assume this is due to color
>     table swapping.  Is there a wm that provides a mechanism for
>     avoiding this ?

Not that I know of.  But notice that if your hardware provides the
hardware analogue of a single 256-entry PseudoColor lookup table (which
is the commonest sort of color machine around, I feel sure), you can't
really avoid this entirely, without giving up some of those 256 colors.
(In general the window won't go black but rather will go "technicolor"
when some other window's colormap gets installed.)

When this swapping happens depends on the window manager's colormap
focus policy.  I feel sure gwm can be configured to support different
colormap policies; perhaps twm can as well.  (No, I haven't the
foggiest clue how in either case.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

schoch@sheba.arc.nasa.gov (Steve Schoch) (12/11/90)

|> > (1) When server and client are resident on the same machine, is there
|> >     a reasonable way to NOT pass messages over the net, but directly
|> >     (e.g. memory-to-memory ??) to enhance performance ?

If your $DISPLAY is unix:0 or :0 the communication will be over UNIX domain
sockets which means that the data will not go through TCP.  UNIX domain
sockets are basically the same as pipes once they are connected.

Of course, this still means that requests will take about 2 memory copies
to get from client to server (one from client memory to kernel memory and
one from kernel memory to server memory).  However, using TCP also gives
the overhead of window-size calculations, checksum verification, IP address
checking, etc.

	Steve

jg@crl.dec.com (Jim Gettys) (12/11/90)

In article <1990Dec10.181808.1528@news.arc.nasa.gov>, schoch@sheba.arc.nasa.gov (Steve Schoch) writes:
> Of course, this still means that requests will take about 2 memory copies
> to get from client to server (one from client memory to kernel memory and
> one from kernel memory to server memory).  However, using TCP also gives
> the overhead of window-size calculations, checksum verification, IP address
> checking, etc.

Not quite true (on many systems).  A long time ago, in a galaxy far, far,
away (MIT), a hack was put into the top tcp_output in the network code, allowing
local TCP connections to avoid all the low level TCP transport costs of
window size, checksumming, etc..  The data copies do of course happen.

I believe this hack got into more recent Berkeley TCP implementations (certainly
got into Ultrix, shortly after it went in at MIT's), and many manufacturers
may now have picked up the optimization.  

-- 
Jim Gettys
Digital Equipment Corporation
Cambridge Research Laboratory

robinro@bomber.ism.isc.com (Robin Roberts) (12/17/90)

The original posting asked about ways to short circuit the net calls to
dump an image into a pixmap/window on the server when the client and server
were on the same host.

An example extension that avoided both the net calls and the parseing of 
the image into digestable chunks was made by Stardent wherein the added a
call XCreateShared Pixmap. The client sent a message to the server describing
the shared memory id of the newly created pixmap { the used that term
instead of image although unlike pixmap the memory organisation is public }.
Then the client could draw / copy data into the pixmap and make ordinary
copy pixmap requests to the server which would have access to the shared
memory.  This is all of course a non-standard extension to MIT's X11R3.

-- 
Robin D. Roberts           | <This space closed for remodeling.  Watch for
Interactive Systems Corp.  |  a new witty quotation scheduled to open in
Calabasas, Calif.          |  the Spring of 1991! >
Internet: robinro@ism.isc.com CompuServe: 72330,1244 GEnie: R.ROBERTS10