etale-cohomology/xcb

A bunch of XCB examples, taken from all over

XCB examples

XCB, the X-protocol C Binding, is the lowest level API to talk to the X server. It's a replacement for the decades-old Xlib API.

This repo contains a few simple examples of XCB usage.

XCB notes

Xlib leads to high latency. Requests needing a reply are synchronous, blocking till the reply comes
XCB is a direct binding of X protocol operations to C functions
The XCB API has 2 layers: XCB_Connection (lower layer), and XCB_Protocol (higher layer)
XCB_connection: connection to the X server, buffering, batching of requests/replies
XCB_Protocol: direct C API to the X protocol
XCB is thread safe (lots of Pthreads locking): each connection is locked against concurrent access with a pthread_mutex, there's blocking during API calls through pthread_cond conditional variables
XCB is best w/ 2 threads: one for requests/replies, one to process events!
Unlike Xlib, there can only be one connection per display!
There's no notion of a screen

X and Xlib notes

Xlib and XCB are the lowest level programming interfaces to X
X11R6 is the protocol, Xlib/XCB is the API to the protocol
X is network-based: apps can run on a remote computer, and the results displayed on a local computer
X is a window system for bitmapped graphics displays (aka memory-mapped graphics)
In bitmapped graphics, each dot/pixel on the screen maps to one or more bits in memory. Apps alter the display simply by writing to display memory
The X protocol has about 120 requests!

A display is a computer with a keyboard, a mouse, and one or more screens. Multiple screens can work together as a single display, with mouse movement allowed to cross physical screen boundaries The program that controls each display is known as a server Graphics are performed by the display server rather than by the client The server maintains complex data structures, including windows, cursors, fonts, and "graphics contexts," as resources that can be shared between clients and referred to simply by resource IDs.

Xlib calls are translated to protocol requests sent via TCP/IP or over Unix domain protocol (IPC?), either to the local server or to another server across the network

X was designed to allow any style of user interface

A single X server can provide display services for any number of screens. A set of screens for a single user with one keyboard and one pointer (usually a mouse) is called a display. X also provides off-screen storage of graphics objects, called pixmaps. Single plane (depth 1) pixmaps are sometimes referred to as bitmaps. Most of the functions in Xlib just add requests to an output buffer. These later execute asynchronously on the X server. Functions that return values of information stored in the server do not return (that is, they block) until an explicit reply is received or an error occurs. Input events (for example, a key pressed or the pointer moved) arrive asynchronously from the server and are queued until they are requested by an explicit call (for example, XNextEvent or XWindowEvent).

A host may start several X server at the same time from different terminals (TTY in GNU/LINUX), this way it allows several displays to be used.

X was designed to provide windows on bitmapped terminals. The code was designed to stress easy portability
the developers of X decided that it should not imply a particular style of user interface
To work over a network, there had to be programs running at both ends of the connection to send and receive the information and to interpret it. The end that controls the display and input devices was named the server. At the other end are clients−−programs written using Xlib to interface with the X protocol

The win_gravity attribute controls the repositioning of subwindows when a parent window is resized. Window gravity is only useful for children placed against or very near the outside edges of the parent or directly in its center: it'll be value for implementing tabs!

GC stores data about how to interpret graphics requests so that the same information does not have to be sent with every request Since GC's store data in the server, they also reduce network traffic you can create several GCs with the different characteristics you need and then switch between them. Data like windows, pixmaps and graphic context are resources stored server-side

Drawing is done by the server! The client merely sends requests, which are placed in a queue! X has a graphics pipeline that consists of 4 stages: pixel selection, coloring (at most 2), plane masking, other masking Most graphics are drawn by simply overwriting the existing graphics!s

XClearWindow clears an entire window. If the window has a background_ pixmap attribute, then the window is redrawn with this tile. If the window has background_pixmap or background_pixel attribute None, then the contents of the window are not changed XClearWindow is not needed to clear a window before redrawing it due to an Expose event, because the server automatically draws the exposed area with the background pixel value or pixmap

Xlib stores more than a kilobyte of data about each X server connection in a structure named Display

Requests always have a “major opcode” identifying the kind of request, and a length field that measures the number of four-byte words needed to contain the entire packet. Responses come in three forms: replies, events, and errors. Replies and errors are sent in response to requests, while events are sent spontaneously.

xim/xom/xlc make up about 44% of the 150k lines of source in Xlib, and about 54% of the compiled size. The cms component contributes roughly 10%, and xkb contributes 15%, to the size of Xlib. The present build system allows Xlib to be built without each of these components, producing a build of Xlib that is about 75% smaller

What are the possible shapes for drawing? Are the only rectangles?
What is the clip_mask in the GC? What is the plane_mask?
Can one erase a drawing without writting background pixels on top?