Well, it seems to work fine (xorg.conf tearfree option, that is). AFAIK wayland compositing also has the problem that clients don't know when they should be done with rendering, as in when the flip is going to happen. I don't know much about how it (wayland, DRI) actually works (as in, can the "client" just render where the compositor told DRI it should without involving the compositor, or does it have to tell the compositor when it rendered).GNOME3 had(has?) many a timing problems.
pengaru|5 years ago
In X, there isn't really a concept of what a completion boundary is. The client asks stuff to be drawn, the display server gets around to it when it gets around to it, and makes the changes visible willy-nilly, eventually becoming consistent with the client state.
If you look at the source for xcompmgr, the event loop is pretty simple and clearly schedules repainting the root window with all newly received damage updates whenever its X socket is drained of new events [0]. This is a pretty arbitrary boundary to perform redrawing on; process scheduling, socket buffer sizes/limits, it's not well controlled at all. The way this is done it will make visible whatever damage events managed to get into this timeslice. If that results in only part of a window being updated, with the rest of the damage part of that "frame" arriving in the next timeslice, POOF, there's a tear.
[0] https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/mast...
cycloptic|5 years ago
(AFAIK random clients should not really be using this though, the intent is for it to get used internally by the GL/Vulkan implementation)