X uses a clientāserver model where an X server program runs on a computer with a graphical display and communicates with various client programs-- each of which may run on different machines. This reverses the common configuration of clientāserver systems, where the client runs on the user's computer and the server runs on a remote computer. This is mainly because the X Window terminology takes the perspective of the program, rather than of the end-user or of the hardware: the remote programs connect to the X server display running on the local machine, and thus act as clients; the local X display accepts incoming traffic, and thus acts as a server.Ā
There are 4 types of packets exchanged between X and its clients in total. These are:
Request: the client requests information from the server or requests it to perform an action. Requests may generate replies, events, and errors.
Reply: the server responds to a request. Not all requests generate replies.
Event: the server sends an event to the client, e.g., keyboard or mouse input, or a window being moved, resized or exposed. Events are selected base on each client's interest which can be specified either a) at the moment of creation b) a change to window's attribute or c) the use of XSelectInput().
Error: the server sends an error packet if a request is invalid. Since requests are queued, error packets generated by a request may not be sent immediately.
It is in the X request and X events that we are interested in. The Xlib functions that send requests to the server usually do not send these requests immediately but store them in a buffer, called the output buffer. The term output in this case refers to the output from the client that is directed to the server: the output buffer can contain all kinds of requests to the server, not only those having a visible effect on the screen.
The output buffer is guaranteed to be flushed ( i.e., all requests done so far are sent to the serverĀ ) per these conditions:
After a call to the functions XSync or XFlush.
After a call to a function that returns a value from the server (these functions block until the answer is received)
Xlib stores the received events in a queue. The client application can inspect and retrieve events from the queue. While the X server sends events asynchronously, applications using the Xlib library are required to explicitly call Xlib functions for accessing the events in the queue. Some of these functions may block; in this case, they also flush the output buffer.
The content of a window is not guaranteed to be preserved if the window of one of its parts are made not visible. In this case, the application is sent an Expose event when the window of one part of it is made visible again. In particular, content is lost if the X server is not maintaining a backing store of the window content. The client can request backing store for a window to be maintained, but there is no obligation for the server to do so. Therefore, clients cannot assume that backing store is maintained. If a visible part of a window has an unspecified content, an event is sent to notify the client that the window content has to be drawn again.
Also, do note that the use of backing_store is not selected by default owing to a certain memory issues as specified here.
Sources: here, here, here, here,Ā and here.