4 ms·

XWayland is a compatibility interface for X apps to still work on Wayland compositors, so it's not mandatory to port everything over to Wayland. But there shou

XWayland is a compatibility interface for X apps to still work on Wayland compositors, so it's not mandatory to port everything over to Wayland. But there should be performance and rendering quality advantages to speaking Wayland natively. Core X for instance has zero concept of a frame or buffer swapping, X apps like games generally get that via GL. So your average X GUI application tends to be inherently flickery/tear-ful, since draws just get sent out to the X server and display whenever. XOrg drivers have implemented various hacks to try minimize those effects, but it's all very vendor-specific[0] and never perfect since it's a fundamental limitation of the X protocol. You can at best eliminate literal tearing[1], but nothing prevents displaying a partially refreshed window full of changing widgets, each implemented as X subwindows in the classic X fashion, because nothing in the core protocol says "Ok, this top-level window update is finished, present it (and its descendants)!". That's not even getting into the issues of high dpi and fractional scaling... [0] https://manpages.debian.org/bookworm/xserver-xorg-video-intel/intel.4.en.html#Option~11 https://manpages.debian.org/bookworm/xserver-xorg-video-inte... [1] https://en.wikipedia.org/wiki/Screen_tearing https://en.wikipedia.org/wiki/Screen_tearing

vidarh 3y ago
Most X servers implement the Xdbe extension for double buffering with clients that supports it, or you can just render into an off screen pixmap first. In other words, if there is tearing or flickering, it's really entirely the clients fault for just blindly choosing to render straight to the window.
- bitwize 3y ago
  But with Wayland you don't actually have to do anything to get flicker-free, tear-free output because Wayland was designed with these goals in mind.
  - vidarh 3y ago
    Of course you do: You need to allocate a buffer, and you need to commit it to the visible display, exactly the same amount of work to do so under X. If anything, I suggest you look at the sheer amount of code required to put anything on screen with Wayland vs. X - Wayland requires a lot of boilerplate, as the presumption is that everyone would use a widget library. As far as design goes, Wayland is absolutely awfully verbose for no good reason.
    - LoganDark 3y ago
      > As far as design goes, Wayland is absolutely awfully verbose for no good reason. Not to mention that so many fundamental things are optional extensions that there are five completely incompatible extensions for each possible API that Wayland leaves out. Like screenshotting.
      - vidarh 3y ago
        I've largely come to the conclusion that 1) X got as bad as it did not for technical reasons but because of designers stuck in the past (see below), 2) Wayland inherited many of the same architecture astronaut attitudes. You see this if you look at e.g. XRender. XRender was a big improvement for X, by providing a set of rendering primitives. Yet at the same time they repeated mistake after mistake from the core protocol. E.g. the flexibility in visuals that mattered when we did have monochrome, 8-bit palettes, 15-bit direct color, 16-bit direct color and 24-bit truecolor graphics output in the same computer lab no longer matters when you can assume that every server can provide RGB24 and RGBA32 visuals, not least because XRender demands this so if a server wants to support XRender, it must support RGB24 and RGBA32 whether or not that's a natural fit for the backend or not. Yet it still makes you iterate through a list of every weird format known to man (and some that feel like they must be alien) even when you want to look up one of the 5 standard formats Xrender dictates that every server must support. Xrender could have just made the relevant request return 5 ints. It's not hard to deal with the current solution, but it's pointless and it makes the server unnecessarily complicated to still support all of those extra visuals that almost nobody will be using, and nobody needs to use. If that was all, it wouldn't be so bad, but this is typical for XRender, and this is why X became unmanageable: They both left the core protocol intact, but each extension they added was just as bloated as the core was. Nothing would stop you from fixing this by bumping a version number and start deprecating requests and introducing replacements. But that only works if you can get buy-in into changes that actually simplifies things, and the XRender extension is a good indication that this was the real problem for X: You'd get buy-in for changes, but changes that only ever added complexity. This was particularly idiotic because Xorg came to pretty much control this space: Almost everyone used the same X server and almost everyone used the same Xlib. They could have bumped the protocol version and started deprecating old functionality whenever they wanted while optionally papering it over in the client lib to give people time to update their clients. So Wayland became a way of escaping that and starting over. And it could have been great if they weren't so afraid of repeating the same complexity mistakes that they repeated the same complexity mistake by proxy by forcing even basic functionality into extensions where there was no ability to reign it in. The Wayland design reliance on extensions made an explosion in complexity virtually guaranteed. I wish they'd have forked Xorg instead, and had the guts to gut it and clean it up: Bump the major version to 12. Set out an aggressive deprecation schedule and ensure a sufficient set of apps would keep working with various calls and visuals yanked out. Optionally add a shim to xlib/xcb to temporarily handle some of the deprecated functionality client side (e.g. most old rendering calls and bitmap font handling could easily be transitioned this way). Then you'd have a base to iterate from where you could iterate step by step from a working starting point. Then maybe we'd all be on something new and working instead of having this ongoing schism that won't be resolved anytime soon.
arp242 3y ago
I'm not convinced the Wayland approach is actually better. It "feels" to have a lot more latency on my (admittedly somewhat old) laptop, which is somewhat disappointing since "better performance" was supposed to be one of the reasons for Wayland in the first place. "Render as quickly as possible (even if imperfect)" is also a viable strategy. Some people seem to really hate it, but I've never even noticed it, much less been bothered by it. I certainly prefer the reduced latency. I'm probably not that special. It very much seems like a trade-off thing, rather than "this is the one true correct way"-thing. Of course, it would be better if Xorg would support both, but that also applies to Wayland.
- pengaru 3y ago
  One of the unfortunate things about Wayland is every compositor will have its own quality of implementation affecting things like latency. With XOrg, especially in the pre-compositing days, you could choose whatever WM you want and it wouldn't have any impact on the rendering performance of X clients. Once the Composite extension was added and everyone started running composited X desktops, that started to change, and the increased latency already started appearing - in an arguably worse architecture than Wayland because there were often three processes involved with lots of IPC/context switches per draw: X-Client->X-Server->X-Compositor->X-Server->CRTC. At least in Wayland it's more like Wayland-Client->Wayland-Compositor->CRTC. If you're unhappy with the rendering latency of your Wayland sessions, it may be worth trying alternative compositors... they likely vary significantly. The Valve/Steam folks have made a minimal one specifically optimized for games/low-latency [0]. I doubt the SteamDeck would be seeing as much success as it is if Wayland were so problematic in this department. [0]: https://github.com/ValveSoftware/gamescope https://github.com/ValveSoftware/gamescope
  - arp242 3y ago
    If most WMs are slower out of the box then Wayland is de-facto slower. "But actually, Wayland is a protocol, and you can use this specialized WM optimized for speed" doesn't change much about that. I don't use a compositing WM. I would have to check how the performance compares to a compositing WM. It's just one more thing that's worse-out-of-the-box with Wayland that I need to find a solution for, while at the same time solving exactly zero issues for me.

vidarh 3y ago

Most X servers implement the Xdbe extension for double buffering with clients that supports it, or you can just render into an off screen pixmap first. In other words, if there is tearing or flickering, it's really entirely the clients fault for just blindly choosing to render straight to the window.

bitwize 3y ago
But with Wayland you don't actually have to do anything to get flicker-free, tear-free output because Wayland was designed with these goals in mind.
- vidarh 3y ago
  Of course you do: You need to allocate a buffer, and you need to commit it to the visible display, exactly the same amount of work to do so under X. If anything, I suggest you look at the sheer amount of code required to put anything on screen with Wayland vs. X - Wayland requires a lot of boilerplate, as the presumption is that everyone would use a widget library. As far as design goes, Wayland is absolutely awfully verbose for no good reason.
  - LoganDark 3y ago
    > As far as design goes, Wayland is absolutely awfully verbose for no good reason. Not to mention that so many fundamental things are optional extensions that there are five completely incompatible extensions for each possible API that Wayland leaves out. Like screenshotting.
    - vidarh 3y ago
      I've largely come to the conclusion that 1) X got as bad as it did not for technical reasons but because of designers stuck in the past (see below), 2) Wayland inherited many of the same architecture astronaut attitudes. You see this if you look at e.g. XRender. XRender was a big improvement for X, by providing a set of rendering primitives. Yet at the same time they repeated mistake after mistake from the core protocol. E.g. the flexibility in visuals that mattered when we did have monochrome, 8-bit palettes, 15-bit direct color, 16-bit direct color and 24-bit truecolor graphics output in the same computer lab no longer matters when you can assume that every server can provide RGB24 and RGBA32 visuals, not least because XRender demands this so if a server wants to support XRender, it must support RGB24 and RGBA32 whether or not that's a natural fit for the backend or not. Yet it still makes you iterate through a list of every weird format known to man (and some that feel like they must be alien) even when you want to look up one of the 5 standard formats Xrender dictates that every server must support. Xrender could have just made the relevant request return 5 ints. It's not hard to deal with the current solution, but it's pointless and it makes the server unnecessarily complicated to still support all of those extra visuals that almost nobody will be using, and nobody needs to use. If that was all, it wouldn't be so bad, but this is typical for XRender, and this is why X became unmanageable: They both left the core protocol intact, but each extension they added was just as bloated as the core was. Nothing would stop you from fixing this by bumping a version number and start deprecating requests and introducing replacements. But that only works if you can get buy-in into changes that actually simplifies things, and the XRender extension is a good indication that this was the real problem for X: You'd get buy-in for changes, but changes that only ever added complexity. This was particularly idiotic because Xorg came to pretty much control this space: Almost everyone used the same X server and almost everyone used the same Xlib. They could have bumped the protocol version and started deprecating old functionality whenever they wanted while optionally papering it over in the client lib to give people time to update their clients. So Wayland became a way of escaping that and starting over. And it could have been great if they weren't so afraid of repeating the same complexity mistakes that they repeated the same complexity mistake by proxy by forcing even basic functionality into extensions where there was no ability to reign it in. The Wayland design reliance on extensions made an explosion in complexity virtually guaranteed. I wish they'd have forked Xorg instead, and had the guts to gut it and clean it up: Bump the major version to 12. Set out an aggressive deprecation schedule and ensure a sufficient set of apps would keep working with various calls and visuals yanked out. Optionally add a shim to xlib/xcb to temporarily handle some of the deprecated functionality client side (e.g. most old rendering calls and bitmap font handling could easily be transitioned this way). Then you'd have a base to iterate from where you could iterate step by step from a working starting point. Then maybe we'd all be on something new and working instead of having this ongoing schism that won't be resolved anytime soon.

arp242 3y ago

I'm not convinced the Wayland approach is actually better. It "feels" to have a lot more latency on my (admittedly somewhat old) laptop, which is somewhat disappointing since "better performance" was supposed to be one of the reasons for Wayland in the first place. "Render as quickly as possible (even if imperfect)" is also a viable strategy. Some people seem to really hate it, but I've never even noticed it, much less been bothered by it. I certainly prefer the reduced latency. I'm probably not that special. It very much seems like a trade-off thing, rather than "this is the one true correct way"-thing. Of course, it would be better if Xorg would support both, but that also applies to Wayland.

pengaru 3y ago
One of the unfortunate things about Wayland is every compositor will have its own quality of implementation affecting things like latency. With XOrg, especially in the pre-compositing days, you could choose whatever WM you want and it wouldn't have any impact on the rendering performance of X clients. Once the Composite extension was added and everyone started running composited X desktops, that started to change, and the increased latency already started appearing - in an arguably worse architecture than Wayland because there were often three processes involved with lots of IPC/context switches per draw: X-Client->X-Server->X-Compositor->X-Server->CRTC. At least in Wayland it's more like Wayland-Client->Wayland-Compositor->CRTC. If you're unhappy with the rendering latency of your Wayland sessions, it may be worth trying alternative compositors... they likely vary significantly. The Valve/Steam folks have made a minimal one specifically optimized for games/low-latency [0]. I doubt the SteamDeck would be seeing as much success as it is if Wayland were so problematic in this department. [0]: https://github.com/ValveSoftware/gamescope https://github.com/ValveSoftware/gamescope
- arp242 3y ago
  If most WMs are slower out of the box then Wayland is de-facto slower. "But actually, Wayland is a protocol, and you can use this specialized WM optimized for speed" doesn't change much about that. I don't use a compositing WM. I would have to check how the performance compares to a compositing WM. It's just one more thing that's worse-out-of-the-box with Wayland that I need to find a solution for, while at the same time solving exactly zero issues for me.