4 ms·

> Sure, it has better performance if there is not a networking protocol in the middle. That's not even true. The DRI3 X11 extension uses the exact same buffer

by sprash 5y ago

> Sure, it has better performance if there is not a networking protocol in the middle. That's not even true. The DRI3 X11 extension uses the exact same buffer swap mechanism like most Wayland compositors. Running locally you get the best of both worlds with X11 already.

bitwize 5y ago
In other words... > So, your X server is really effectively nothing more than a shitty Wayland compositor. Couple of things: 1) you use DRI3, you lose network transparency. KDE apps run like a pig stuck in shit over network links because Qt on X was built to take advantage of the massive speed of DRI3. 2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes this by making the display server, window manager, and compositor all one process. Wayland solves problems you do have, you just don't know you have them.
- sprash 5y ago
  > So, your X server is really effectively nothing more than a shitty Wayland compositor. No it is a much better Wayland compositor because unlike Xwayland it provides full backwards compatibility. You even need much less boiler plate code to get a file descriptor on X11 as compared to Wayland. > Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. This is only makes a difference for rare events like moving/resizing windows. For static window positions it is the exact same path as Wayland. In practice Wayland had historically even much worse latency than X11. This has only been fixed a few years ago. Latency has low priority for Wayland developers. And as such Wayland does not beat uncomposited X11 in latency to this day.
  - md8z 5y ago
    The stuff that's not backwards compatible in XWayland is mostly already broken by X compositors anyway and needed to be reimplemented, so that's why there wasn't much incentive to fix that. I've seen some of your comments around and I'm really struggling to figure out what your use case is. "This is only makes a difference for rare events like moving/resizing windows." This is actually wrong, that type of split affects the rendering of every single frame. Also, uncomposited X11 is a bad idea for a number of other reasons, the only reasonable comparison to make there is composited X versus Wayland, which is what all the benchmarks I've seen are aiming for.
    - deleted 5y ago
      [deleted]
- alerighi 5y ago
  > 2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes this by making the display server, window manager, and compositor all one process. That also mean that you have a single process that if it crashes you loose your entire desktop session crashes. In the old X days I used to have my compositor crash a lot of times (good old days of Compiz with a ton of effects), but everything else was still functional, and I could simply restart it without loosing my entire desktop session. Or you changed the settings on GNOME, in the past just restart the WM, with Wayland of course you have to log out and login again. Also, things that on X were simple (for example having an application that captures the screen) are difficult in Wayland, and the only way to do so is to incorporate that functionality into the window manager itself, that becomes a monolith very quickly. Speaking about latency, to me is stupid. Like I said, in the old days of Debian 6, with a core2 and integrated graphics I used to run GNOME 2 with Compiz, I had smooth graphical effects and it did run fine, with a memory usage less than 100Mb in idle. Nowadays we have hardware that is orders of magnitude faster and we have more problems that back in the days we didn't.
  - kaba0 5y ago
    But you also have hardware that is orders of magnitude harder to fill, eg 4k120fps monitors for example.

by sprash 5y ago

bitwize 5y ago

In other words... > So, your X server is really effectively nothing more than a shitty Wayland compositor. Couple of things: 1) you use DRI3, you lose network transparency. KDE apps run like a pig stuck in shit over network links because Qt on X was built to take advantage of the massive speed of DRI3. 2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes this by making the display server, window manager, and compositor all one process. Wayland solves problems you do have, you just don't know you have them.

sprash 5y ago
> So, your X server is really effectively nothing more than a shitty Wayland compositor. No it is a much better Wayland compositor because unlike Xwayland it provides full backwards compatibility. You even need much less boiler plate code to get a file descriptor on X11 as compared to Wayland. > Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. This is only makes a difference for rare events like moving/resizing windows. For static window positions it is the exact same path as Wayland. In practice Wayland had historically even much worse latency than X11. This has only been fixed a few years ago. Latency has low priority for Wayland developers. And as such Wayland does not beat uncomposited X11 in latency to this day.
- md8z 5y ago
  The stuff that's not backwards compatible in XWayland is mostly already broken by X compositors anyway and needed to be reimplemented, so that's why there wasn't much incentive to fix that. I've seen some of your comments around and I'm really struggling to figure out what your use case is. "This is only makes a difference for rare events like moving/resizing windows." This is actually wrong, that type of split affects the rendering of every single frame. Also, uncomposited X11 is a bad idea for a number of other reasons, the only reasonable comparison to make there is composited X versus Wayland, which is what all the benchmarks I've seen are aiming for.
  - deleted 5y ago
    [deleted]
alerighi 5y ago
> 2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes this by making the display server, window manager, and compositor all one process. That also mean that you have a single process that if it crashes you loose your entire desktop session crashes. In the old X days I used to have my compositor crash a lot of times (good old days of Compiz with a ton of effects), but everything else was still functional, and I could simply restart it without loosing my entire desktop session. Or you changed the settings on GNOME, in the past just restart the WM, with Wayland of course you have to log out and login again. Also, things that on X were simple (for example having an application that captures the screen) are difficult in Wayland, and the only way to do so is to incorporate that functionality into the window manager itself, that becomes a monolith very quickly. Speaking about latency, to me is stupid. Like I said, in the old days of Debian 6, with a core2 and integrated graphics I used to run GNOME 2 with Compiz, I had smooth graphical effects and it did run fine, with a memory usage less than 100Mb in idle. Nowadays we have hardware that is orders of magnitude faster and we have more problems that back in the days we didn't.
- kaba0 5y ago
  But you also have hardware that is orders of magnitude harder to fill, eg 4k120fps monitors for example.