Before a program can use a display, it must establish a connection to the X server driving the display. Once users establish a connection, they can use the Xlib macros and functions to return information about this display, such as image format size and depth.
The following information describes how to open windows. The two major sections are as follows:
To open a connection to the X server controlling a specified display, use the XOpenDisplay function. This function returns a display structure that serves as the connection to the X server. This display structure contains information about the X server and connects the specified hardware display to the server through Transmission Control Protocol (TCP) or UNIX domain sockets. If the host name is a host system name and a : (colon) separates the host name and display number, the XOpenDisplay function connects the host and the display using TCP sockets. If the host name does not exist, or if unix and a : (colon) separates it from the display number, the XOpenDisplay function connects the host and the display using UNIX domain sockets.
A single server can support any or all of these transport mechanisms simultaneously.
The display name or DISPLAY environment variable is a string with the following format:
HostName:Number.Screen
For example, you can use the following format to specify screen 0 display 2 on the system named Dave:
Dave:2.0
Applications should not directly modify any part of the Display and Screen data structures. These structures should be considered read-only by the user, but they can be changed by specified functions or display macros.
Note: Communication from the Xlib to the X server is handled in one of the following three ways:
See Shared Memory Transport (SMT) for more information.
Communication from Xlib to the X windows server is handled by UNIX domain sockets, TCP domain sockets, and Shared Memory Transport sockets. UNIX domain sockets constitute a mechanism that was an inherited mechanism for protocol transport. TCP sockets are used on a system when the application (client) running is on a remote machine. Shared Memory Transport sockets constitute a newly developed mechanism that is specifically designed for the X server.
The Shared Memory Transport sockets mechanism was developed to increase performance of the transfer data from the client application (through Xlib) to the X server. The figure shows how data would typically flow from a client through Xlib and on to the X server.
The default protocol transport method is a convention inherited from the Massachusetts Institute of Technology (MIT) which is the fastest transport method available.
Data has shown that the communications overhead for the local X applications can be significant and can be improved by using SMT sockets rather than UNIX or TCP sockets as the transport mechanism. The standard communication mechanism for local X clients is UNIX domain sockets. This design provides a set of services to facilitate the use of shared memory as a transport mechanism for local clients.
The Shared Memory Transport (SMT) design assists in eliminating unnecessary data movement. When UNIX domain sockets are used for communication, the data must be copied twice to move it between processes. This data is copied into the kernel on "sends" and out of the kernel on "receives." By using a shared memory segment for the data, both the client and server processes can access the same data. This saves one or more copies of the data.
When multiple applications are running on a single server, little data may be transferred to or from a client before another client requires service. In this type of scenario, the server spends much of its time in the [select] system call in order to switch to another process.
The select system call contains much overhead that the X server does not need. The SMT design implements a proprietary select called smselect. This SMT system call eliminates much of the unnecessary overhead, minimizing the process switching time between the applications, and improving performance.
The X server uses SMT by default, which is transparent to the user (except for performance differences). The user can, however, make use of two environment variables that can change the way the transport layer works. These environment variables are: DISPLAY and X_SHM_SIZE.
DISPLAY is an existing environment variable that is commonly manipulated by X server users. This variable is used to specify the connection to a specific X server. It can specify any number of either local or remote X servers. By default, the DISPLAY environment variable is set to :screen# . This convention specifies that the user would like to connect to the X server specified by screen# and use the fastest available transport method. If the DISPLAY variable is set to unix:screen# then UNIX domain sockets are used. If the variable is set to hostname:screen# then TCP sockets are used to transport the data to the remote X server.
X_SHM_SIZE is an environment variable to X11R5 1.2.3 (Release 3.2.4). This variable can be used to change the size of the client-to-server and server-to-client buffer sizes. The default buffer size is 64K bytes, the minimum size is 16K bytes, and the maximum size is 252K bytes. The user may wish to change the size of the buffers proportionally to the specific application needs. For example, large buffers for large data sets, and small buffers for small data sets.
It is important to note that the Shared Memory Transport mechanism is not the same as the Shared Memory Extension shipped by MIT. The extension operates solely on pixmaps and images and requires that the client application have detailed knowledge of the transport mechanism. In this scenario, the client makes specific calls to the server-side extension to gain addressability to a shared memory segment simultaneously with the server.
Shared Memory Transport, on the other hand, utilizes the shared memory segment to transport all data (not just pixmaps and images) to and from the X server. The client is not required to do any special processing. The Xlib program handles the transport mechanism for the client application.
