4 ms·

> It is fundamentally broken. The Wayland developers disagree with you: https://wayland.freedesktop.org/faq.html#heading_toc_j_5 https://wayland.freedesktop.o

> It is fundamentally broken. The Wayland developers disagree with you: https://wayland.freedesktop.org/faq.html#heading_toc_j_5 https://wayland.freedesktop.org/faq.html#heading_toc_j_5 "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X." They themselves say they could have fixed X. They just didn't want to. And now they've predictably just made a new mess.

kaba0 6y ago
https://www.youtube.com/watch?v=GWQh_DmDLKQ https://www.youtube.com/watch?v=GWQh_DmDLKQ Just watch it.
- wander_homer 6y ago
  Did you watch and understand it? This presentation is nothing but a highly one-sided and subjective talk, which gladly bends the truth or leaves out crucial details to get a good laugh from the audience. Take the whole part about "X terrible IPC" and slow startup time as an example. It's portrayed as if slow startup time is an inherent flaw of X due to blocking IPC calls. However he forgot to mention, that non-blocking calls had been there for years and big projects like Qt were using them exclusively instead of the blocking Xlib calls. Then he goes on to say that Chromium's startup time is so slow because at minimum it waits half a second for replies from the X server. So let's get some current numbers on a T420s for starting up Chromium and immediately closing it: Weston + Chromium (Wayland mode): 731.3 ms ± 39.4 ms Sway + Chromium (Wayland mode): 688.2 ms ± 22.7 ms Sway + Chromium (XWayland): 667.2 ms ± 16.6 ms X.org + i3 + Chromium: 661.3ms ± 17.2 ms I was actually surprised to see how little difference there is, if there's any at all. So either his numbers don't apply anymore and X.org is not a bottleneck anymore, or Wayland became a similar bottleneck, or his numbers never made sense in the first place, especially since he never bechmarked the Wayland part. Edit: On GNOME Shell Chromium also starts slightly faster with X.org with 0.6 - 0.7s and > 0.7s in Wayland mode. *updated benchmark results with the actual results from hyperfine (10 runs each)
  - kaba0 6y ago
    The video is quite old. And I think you should add a compositor on top of i3 to measure the same thing. The whole point of the talk was that when a compositor is used (which should absolutely be used because with increasing resolutions tearing will just get more visible), X has pretty much a useless role in the whole situation. That is, you’ve got yourself an architectural problem. Which is no surprise, X had been here forever. But maybe it should no longer the be the abstraction we build our graphics on.
    - wander_homer 6y ago
      With X.org + i3 + picom (GLX backend, animations and vsync enabled) I get: 665.8 ms ± 19.3 ms So it doesn't seem to have any significant influence either.
      - kaba0 6y ago
        Thanks for benchmarking, but as I mentioned, this was/is not a significant problem that would give way for Wayland. What I wrote in the second part of my comment is.
the_why_of_y 6y ago
The problem with X11 was never that you can't add things to it, the problem is that you can't remove things from it.
- destructionator 6y ago
  First, this isn't true - watch the youtube the other person in this thread put where he tells a story about how they deleting about 1/3 of the code (15:19), but secondly even if they didn't, why is that a problem? Breaking user's applications isn't actually a virtue.

kaba0 6y ago

https://www.youtube.com/watch?v=GWQh_DmDLKQ https://www.youtube.com/watch?v=GWQh_DmDLKQ Just watch it.

wander_homer 6y ago
Did you watch and understand it? This presentation is nothing but a highly one-sided and subjective talk, which gladly bends the truth or leaves out crucial details to get a good laugh from the audience. Take the whole part about "X terrible IPC" and slow startup time as an example. It's portrayed as if slow startup time is an inherent flaw of X due to blocking IPC calls. However he forgot to mention, that non-blocking calls had been there for years and big projects like Qt were using them exclusively instead of the blocking Xlib calls. Then he goes on to say that Chromium's startup time is so slow because at minimum it waits half a second for replies from the X server. So let's get some current numbers on a T420s for starting up Chromium and immediately closing it: Weston + Chromium (Wayland mode): 731.3 ms ± 39.4 ms Sway + Chromium (Wayland mode): 688.2 ms ± 22.7 ms Sway + Chromium (XWayland): 667.2 ms ± 16.6 ms X.org + i3 + Chromium: 661.3ms ± 17.2 ms I was actually surprised to see how little difference there is, if there's any at all. So either his numbers don't apply anymore and X.org is not a bottleneck anymore, or Wayland became a similar bottleneck, or his numbers never made sense in the first place, especially since he never bechmarked the Wayland part. Edit: On GNOME Shell Chromium also starts slightly faster with X.org with 0.6 - 0.7s and > 0.7s in Wayland mode. *updated benchmark results with the actual results from hyperfine (10 runs each)
- kaba0 6y ago
  The video is quite old. And I think you should add a compositor on top of i3 to measure the same thing. The whole point of the talk was that when a compositor is used (which should absolutely be used because with increasing resolutions tearing will just get more visible), X has pretty much a useless role in the whole situation. That is, you’ve got yourself an architectural problem. Which is no surprise, X had been here forever. But maybe it should no longer the be the abstraction we build our graphics on.
  - wander_homer 6y ago
    With X.org + i3 + picom (GLX backend, animations and vsync enabled) I get: 665.8 ms ± 19.3 ms So it doesn't seem to have any significant influence either.
    - kaba0 6y ago
      Thanks for benchmarking, but as I mentioned, this was/is not a significant problem that would give way for Wayland. What I wrote in the second part of my comment is.

the_why_of_y 6y ago

The problem with X11 was never that you can't add things to it, the problem is that you can't remove things from it.

destructionator 6y ago
First, this isn't true - watch the youtube the other person in this thread put where he tells a story about how they deleting about 1/3 of the code (15:19), but secondly even if they didn't, why is that a problem? Breaking user's applications isn't actually a virtue.