3 ms·
This got me curious about how using xcompmgr causes flickering. My intuition would tell me the opposite would be true.
by CyberRabbi 6y ago
This got me curious about how using xcompmgr causes flickering. My intuition would tell me the opposite would be true.
- pengaru 6y agoThe core X protocol doesn't have any actual coordination of frames becoming ready to display. There's isn't even a concept of a frame or page at all. There was an extension added in an attempt to fix this situation, IIRC it's the xdbe extension, but I don't believe it gained much traction. If you look at the implementation of xcompmgr and the extensions introduced to make compositing possible, namely Composite and DAMAGE, they too don't have any frame-oriented coordination. So it's just more racy uncoordinated capacitance in the immediate mode rendering pipeline of X. Your X requests logically just throw things on the screen as they occur. There may or may not be a compositor in the middle of that. When the compositor is scheduled and how much of your X requests sitting in the queue become processed as part of the same timeslice is fairly non-deterministic. There's unpredictable scheduling occurring at the kernel level, the compositor process's event handling, and the X display server's client multiplexing level. There are some good reasons for a replacement like wayland, this area is definitely one of them.
- CyberRabbi 6y agoGot it, so there’s no X client request along the lines of “the frame is fully drawn.” I assumed there was and that the compositor would take advantage of that, doing all the double buffering itself.