1. 10
  1.  

  2. 4

    A lot of this comes with caveats. For example, the assertion that X11 windows are rectangles is true, except in the presence of the Shape extension, which allows you to make a window the union of a set of rectangles. To me knowledge, this extension is used by precisely two applications: xclock and xeyes.

    Render each top level window and all its descendant windows (UI elements) to an off-screen, in-memory buffer, instead of directly to the hardware.

    Again, this is true, but doing it that way is slow (this is what OS X 10.0 did and everyone complained). The Composite and Render extensions were designed to avoid needing to do that. They provide opaque handles to the rendered contents of the windows and allow transforms to be applied to them. This means that every window can render directly to a GPU texture and then the compositing window manager can composite them without having to pull data back across the bus (that is probably not such a big deal now, but AGP was incredibly asymmetric and you could write data to the GPU a lot faster than you could pull it back). This is really important for things like GLX, where you want to render complex 3D scenes at 60+ frames per second and you really, really don’t want to be pulling the rendered frame back from the GPU (or doing the GL rendering on the CPU), compositing on the CPU, and then shipping the data back.

    Part II tells you that XCB is better than XLib, and then uses XLib for the examples, which is sad. It’s ages since I wrote a (simple!) compositing window manager, but XCB was much nicer to work with in a program that had a run loop, with just a little bit of wrapping of the responses as promises.

    The thing that’s often missed with XCB is that the ‘C’ in X C Bindings is probably the least interesting bit. Most of the code in XCB is machine generated from XML descriptions of the protocols. You can consume these from any other language and generate X ${LANG} Bindings without ever needing to go via C FFI.