[immibis]

Wayland has a philosophy of "every frame is perfect", which means fixing every race condition. However, X11 doesn't have this philosophy. If the window manager is slow and doesn't respond to a notification that a window has been resized, drawing the new window content over the old borders is the correct thing to do. What sense does it make to freeze the whole display just for a window border?

Similarly, tearing gets pixels to the screen faster.

[silon42]

Reacting somehow to user input, even if not perfect, is more important for me... That's why we have HW cursors, and frame interpolation in games, etc...

[gf000]

HW cursor is an implementation detail, and are used by basically every wayland implementation.

And reacting is one thing, big black rectangles blinking on screen is another.

[speed_spread]

Perfect frames is what Mac and Windows provide and what Linux should also aim for. Border tearing is a display bug, correctness should come first, Wayland's approach is right. X was designed for CPU and IO constraints that no longer apply. _Graceful_ degradation of slow UI should lower the frame rate, not compromise rendering of individual frames.

[hulitu]

> Perfect frames is what ... Windows provide

Citation needed. Windows has its own share of graphics bugs, even on "corporate" hardware (HP).

[speed_spread]

Well, exactly. Windows does try to provide perfect frames. If the display glitches, it's considered as bug rather than the momentarily acceptable degradation that OP was praising X for.

[Maskawanian]

Tearing and hidpi is why I left Linux for Windows between 2012 ans 2022. Once wayland was good enough I returned. Tearing is awful, and should be opt in (which wayland provides), not opt out.

[jcelerier]

Conversely, I much prefer lowest latency at the cost tearing; when I'm forced to use windows I generally disabled the compositor there too whenever i could (I certainly don't use one under Linux and that's one of my reasons for being there). I find macOS unuseable, even on brand new top-end mac studios the input lag and slow reaction of the OS to... any user input, is frightening when you're used to your computer reacting instantly.

[mananaysiempre]

The races I recall being described were substantially worse, but that’s largely beside my point.

My point is that, now that bare fillrate and framebuffer memory haven’t been a limiting factor for 15 to 20 years, it is a reasonable choice to build a desktop graphics system with the invariant of every frame being perfect—not even because of the user experience, but because that allows the developer to unequivocally classify every imperfect frame as a bug. Invariants are nice like that. And once that decision has been made, you cannot have asynchronous out-of-process window management. (I’m not convinced that out-of-process but synchronous is useful.) A reasonable choice is not necessarily the right choice, but neither is it moronic, and I’ve yet to see a discussion of that choice that doesn’t start with calling (formerly-X11) Wayland designers morons for not doing the thing that X11 did (if in not so many words).

To be clear, I’m still low-key pissed that a crash in my desktop shell, which was deliberately designed as a dynamic-language extensibility free-for-all in the vein of Emacs or TeX, crashes my entire graphical session, also as a result of deliberate design. The combination of those two reasonable decisions is, in fact, moronic. But it didn’t need to be done that way even on Wayland.

[gf000]

> To be clear, I’m still low-key pissed that a crash in my desktop shell, which was deliberately designed as a dynamic-language extensibility free-for-all in the vein of Emacs or TeX, crashes my entire graphical session, also as a result of deliberate design. The combination of those two reasonable decisions is, in fact, moronic. But it didn’t need to be done that way even on Wayland.

This is not a given, though. It's entirely feasible to have a stable "display manager/server" with an extension/plugin system where your WM of choice would sit. Crashing the latter should not bring down the former.