| > please just let Xlib die I don't have arguments against the point about Xlib. However, I struggle to use its alternative XCB. XCB doesn't have enough documentation to understand how to use it. In fact, I even looked at the source code of Qt and GTK, but the usage doesn't explain the XCB API. I'd really appreciate if you share with me the data you have. The only thing which I found recently is the wrapper from System76 https://pop-os.github.io/libcosmic/tiny_xlib/index.html. However, it's not a documentation still. I just hope to find some usages of the wrapper and communicate with the original API. > if you ignore the existence of Wayland How did you conclude it? I even mentioned it in the article. I don't use it - it's true. However, I can't wait to do it. I've been trying for a couple of years now. Regrettably, I experience various technical difficulties every time. As a result, I still use my i3. > For something like fast visualizations, you should really go with something that does offscreen rendering and then blits the result. Do you mean double buffering? > though obviously modern tools should use GPU rendering Would you mind elaborating on it? |
Re offscreen rendering: This is orthogonal to double buffering but refers to the way modern compositing desktops (including Wayland) work. The application renders the window image into an offscreen surface which is then handed off to the compositor, which blits it to the screen.
Re GPU rendering: You can draw rectangles on a surface on the CPU by simply setting pixel color values in a loop, or you can draw them on the GPU by sending a list of rectangles and have the GPU do the rasterization of the rectangles. Toolkits like Qt or Gtk can do both, depending on the backend that is selected, and will typically default to GPU rendering on modern desktops.