[gens]

Screen tearing under X11 is more or less not a problem anymore. HIDPI, yes, but only for multiple monitors (maybe even just programs that don't support it properly ?). Security... eh, yes and no (Xorg can be ran as a normal user).

The actual good thing about Wayland is that it simplifies things. While the bad thing is that it needs some kind of extensions for even the basic things a desktop needs, and that (AFAIK) freeGNOMEdesktop is in charge now.

[pengaru]

> Screen tearing under X11 is more or less not a problem anymore.

For GLX/DRI clients where there's an actual concept of swapping buffers w/vsync, sure, but for classical X clients this is not true.

X got extensions for double buffering at one point, but practically nobody uses them.

There is no concept of a "completed frame ready for presentation" in core X, there's no way to really fix this without ceasing to be X (hello, Wayland). X compositors literally just drain event queues of X requests and throw shit on-screen when the event loop gets around to it. If that presents a partially updated window, so be it. GTK+/GNOME folks added "frame clocks" to try work around it, but not everything is a modern-ish GTK+ app, nor do all compositors implement it.

If there's anything Wayland fixes that really required such an upheaval to fix, it's flicker/tear-free compositing.

[gens]

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]

If Wayland is throwing partially constructed buffers on-screen, it's the client's fault for submitting them unfinished.

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]

There is a wayland protocol called presentation-time that's supposed to provide precise timing information to clients, GNOME just merged support for it two days ago: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484

(AFAIK random clients should not really be using this though, the intent is for it to get used internally by the GL/Vulkan implementation)