james@adt.UUCP (james cerrato) (11/01/90)
We are building a graphics application using X11R4 and are using
X Window System - C Library and Protocol Reference
by Gettys, Newman and Scheifler
as our guide to using X. In the introduction it states
"For the best performance, when the client and server reside on the same
machine, communication between them is often implemented using shared
memory."
I have asked other X programmers and they don't know about this. The question
I have is if this 'shared memory' communication is something that the
application builder must specify in some way (and how?) or if this is
done by the X Server without any changes in an application.
Thanks in advance for any info on this subject, or any related info about
how to optimize X applications.
James Cerrato
Associative Design Technology
508-366-9166
adt!james@bu.eduken@msc.EDU (Ken Chin-Purcell) (11/02/90)
James Cerrato writes: |> We are building a graphics application using X11R4 [...] |> "For the best performance, when the client and server reside on the same |> machine, communication between them is often implemented using shared |> memory." That is probably too sweeping of a statement. For example, the communication between client and server on a DECstation 5000 (fastest X I've used so far) doesn't use shared memory, and it is very quick. A shared memory connection can give a performance kick when transffering a lot of data, such as with an XPutImage or XGetImage call. 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. However, the MIT X11R4 server doesn't build on the SGI, so we can't use the shared memory extension. For my application XPutImage isn't a bottleneck. Currently I'm using the MIT X11R4 distribution to build clients. I run my X clients against the SGI X11R3'ish server. Except for a bug with pulldown menus in Motif my clients are functional, but not very fast. The performance problem though is not the connection, it's that SGI hasn't optimized their server yet. 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. -- -- Ken
jym@sgi.com (Administration Training Course) (11/06/90)
Ken from MSC writes: > >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. SGI is currently working on improved X performance and a higher level of integration between X and the GL. More on this later. thanks, jim terhorst X and Motif Product Manager (SGI)
karlton@sgi.com (Phil Karlton) (11/08/90)
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