5 ms·

> multiple monitors You are talking about a very rare niche case where one monitor runs with VRR and the other doesn't. Everything else is handled just fine wi

by sprash 3y ago

> multiple monitors You are talking about a very rare niche case where one monitor runs with VRR and the other doesn't. Everything else is handled just fine with X. > screen tearing. "No screen tearing" just means forced vsync which is easily possible on X11 with a configuration switch or by using a compositor. Actually forced vsync is one of the great disadvantages of Wayland because it always comes at the cost of higher latency. > Wayland rocks those two challenges. And it sucks in every other challenge. Most importantly standardization and development. The Wayland API ecosystem is ultra developer unfriendly and complicated and will pose serious harm to the FOSS landscape which thrives on hobbyist and niche applications. It's so bad it wouldn't be far fetched to call it sabotage. (E.g. look at the hello world: https://github.com/emersion/hello-wayland/blob/master/main.c https://github.com/emersion/hello-wayland/blob/master/main.c it's a complete mess)

onli 3y ago
To be fair, I actually ran a system recently (Surface Tablet with integrated intel graphics) where the screen tearing on X just wasn't solvable. Neither with settings in the xorg.conf nor with a compositor could I get Youtube videos to not tear on fast movements. If Wayland really would solve that for those machines - while being deactivable where it counts - that would be a big plus even for me.
- nalllar 3y ago
  Currently you can't turn off vsync on wayland, except some limited cases involving full screen apps with direct scanout that may not even be implemented in your compositor or may not be possible due to missing implementation for async page flips with atomic modesetting. Due to design issues relating to implicit sync with wayland any misbehaving app can cause your entire desktop to drop frames so if you're a multi monitor user expect stutters when the browser you have open in the background was a little too slow. Or worse if an app is badly broken [1] The good news is that all of this is fixable. Windows has forced compositing for most cases and it performs much more consistently. A browser taking a while to render can't hang unrelated windows' composition. Wayland compositors can get there too eventually by moving to explicit sync APIs [2]. For now if you do care about these issues staying on compositorless X is the least bad option. [1]: https://github.com/ascent12/compositor-killer https://github.com/ascent12/compositor-killer [2]: https://www.collabora.com/news-and-blog/blog/2022/06/09/bridging-the-synchronization-gap-on-linux/ https://www.collabora.com/news-and-blog/blog/2022/06/09/brid...
  - JoshuaRogers 3y ago
    Oh my goodness. Is that’s what’s been going on? I’ve noticed that when I open one particular browser on my desktop that the entire display freezes for roughly a second before it becomes responsive again.
jwells89 3y ago
Last I knew multimonitor with mixed DPIs (an increasingly common situation with laptops standardizing around HiDPI displays) was messy under X, with xconf fiddling required to get things working well.
- sprash 3y ago
  This is not a problem with X. DPI and pitch information is accessible via the xrandr extension. It's GNOME and GTK that arbitrarily chooses to ignore that information.
  - vetinari 3y ago
    The problem with X is that all X11 screens have to have same DPI (and few other things, like color depth). Which is quite a problem when you have mixed-DPI displays. Now the separate X11 displays do not have this limitation, but they have other ones: like not being able to move your window from one to another, without restarting the app. Historically, there was only one app, that was capable of changing the display without restart: XEmacs. For all the others, I have my doubts, that users would accept such limitations. Now, both Xinerama and Xrandr standardized on using X11 screens for multi-monitor displays for exactly this reason. With displays roughly with same DPI and the graphics becoming truecolor, it wasn't really problem. But nowadays, it is. That is mixed-DPI hardware. Another issue with your argument is, that "DPI and pitch information is accessible via xrandr extension". Yes, it it, that is true. The problem is, that it is one-way street. The client can read that, then it can respect that and adjust its rendering... but it doesn't have to. The client is free to ignore all that. Now the display server has the problem, that it doesn't know, how the client decided: should it upscale the client, or not? Nobody knows, all the display server has is an opaque bitmap. With wayland, the client must explicitly set the scale, communicate it do the display server, so then the compositor knows, how to handle that surface. It can even transparently downscale the surface, when the user moves it from HiDPI to normal-DPI display. Something impossible on X11.
chlorion 3y ago
How is that interface unfriendly? The basic idea here is that you provide some callback functions the handle events, setup a framebuffer with mmap, and register your surface and framebuffer with the compositor. There is nothing complicated or messy going on here. This is also the low level interface, most people will not being using this directly and instead will be using a GUI library like GTK or whatever. I don't know very much C and I have been able to get a "hello world" wayland window setup and displaying some silly graphics with cairo in a few hours or less.
- sprash 3y ago
  For my personal taste it's already a mess but for the the average masochist it's maybe bearable. The real mess starts from here though: - Wayland can not render strings. You need something external just to render some other text than "hello world". And depending on the library text rendering will look different for each application. - Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely. - If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor.
  - chlorion 3y ago
    To me these are all advantages, not disadvantages. Wayland is not X11 and doesn't want to be, it doesn't implement even a fraction of what X11 did and that is an intentional design choice! Wayland does not provide any graphics drawing primitives at all. It only sets up a handle to some shared memory and expects the client to do all drawing. I think the point here is that you shouldn't be using the display protocol to render text in the first place. If you want to draw text you use a library that is designed for that task rather than shoving that functionality into the compositor and into the Wayland protocol itself. >- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely. You don't have to use a thread to do this! You aren't forced to block and wait for the callbacks, you can implement your own event loop and check for messages when you want to! >- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor. I think it's good that clients can't capture the screen without permission, and I think using dbus for IPC is very reasonable, but I don't know anything about pipewire or the compatibility stuff. Also I think it's fair to not like some of these design choices for sure, but it would probably be better for people who like X11's design to continue to use X11 rather than trying to force Wayland into an X11 clone. X11 will be around for a very long time so I don't think anybody will be forced to stop using it any time soon, and people can pick it up if development stops!
djha-skin 3y ago
Not really that niche when you have a 4K laptop hooked up to the 1080p monitors that you were able to buy because it was on your own dime and you wanted to go the affordable route. Every time I do that on X, The only thing I can do is downscale my 4K laptop screen to 1440, I can't set a fractional scale for it while still preserving reasonable performance. And no one cares about standardization and development. They just want to use their blasted laptop. I don't know about any of that stuff, I just know Wayland works better out of the box.

by sprash 3y ago

onli 3y ago

To be fair, I actually ran a system recently (Surface Tablet with integrated intel graphics) where the screen tearing on X just wasn't solvable. Neither with settings in the xorg.conf nor with a compositor could I get Youtube videos to not tear on fast movements. If Wayland really would solve that for those machines - while being deactivable where it counts - that would be a big plus even for me.

nalllar 3y ago
Currently you can't turn off vsync on wayland, except some limited cases involving full screen apps with direct scanout that may not even be implemented in your compositor or may not be possible due to missing implementation for async page flips with atomic modesetting. Due to design issues relating to implicit sync with wayland any misbehaving app can cause your entire desktop to drop frames so if you're a multi monitor user expect stutters when the browser you have open in the background was a little too slow. Or worse if an app is badly broken [1] The good news is that all of this is fixable. Windows has forced compositing for most cases and it performs much more consistently. A browser taking a while to render can't hang unrelated windows' composition. Wayland compositors can get there too eventually by moving to explicit sync APIs [2]. For now if you do care about these issues staying on compositorless X is the least bad option. [1]: https://github.com/ascent12/compositor-killer https://github.com/ascent12/compositor-killer [2]: https://www.collabora.com/news-and-blog/blog/2022/06/09/bridging-the-synchronization-gap-on-linux/ https://www.collabora.com/news-and-blog/blog/2022/06/09/brid...
- JoshuaRogers 3y ago
  Oh my goodness. Is that’s what’s been going on? I’ve noticed that when I open one particular browser on my desktop that the entire display freezes for roughly a second before it becomes responsive again.

jwells89 3y ago

Last I knew multimonitor with mixed DPIs (an increasingly common situation with laptops standardizing around HiDPI displays) was messy under X, with xconf fiddling required to get things working well.

sprash 3y ago
This is not a problem with X. DPI and pitch information is accessible via the xrandr extension. It's GNOME and GTK that arbitrarily chooses to ignore that information.
- vetinari 3y ago
  The problem with X is that all X11 screens have to have same DPI (and few other things, like color depth). Which is quite a problem when you have mixed-DPI displays. Now the separate X11 displays do not have this limitation, but they have other ones: like not being able to move your window from one to another, without restarting the app. Historically, there was only one app, that was capable of changing the display without restart: XEmacs. For all the others, I have my doubts, that users would accept such limitations. Now, both Xinerama and Xrandr standardized on using X11 screens for multi-monitor displays for exactly this reason. With displays roughly with same DPI and the graphics becoming truecolor, it wasn't really problem. But nowadays, it is. That is mixed-DPI hardware. Another issue with your argument is, that "DPI and pitch information is accessible via xrandr extension". Yes, it it, that is true. The problem is, that it is one-way street. The client can read that, then it can respect that and adjust its rendering... but it doesn't have to. The client is free to ignore all that. Now the display server has the problem, that it doesn't know, how the client decided: should it upscale the client, or not? Nobody knows, all the display server has is an opaque bitmap. With wayland, the client must explicitly set the scale, communicate it do the display server, so then the compositor knows, how to handle that surface. It can even transparently downscale the surface, when the user moves it from HiDPI to normal-DPI display. Something impossible on X11.

chlorion 3y ago

How is that interface unfriendly? The basic idea here is that you provide some callback functions the handle events, setup a framebuffer with mmap, and register your surface and framebuffer with the compositor. There is nothing complicated or messy going on here. This is also the low level interface, most people will not being using this directly and instead will be using a GUI library like GTK or whatever. I don't know very much C and I have been able to get a "hello world" wayland window setup and displaying some silly graphics with cairo in a few hours or less.

sprash 3y ago
For my personal taste it's already a mess but for the the average masochist it's maybe bearable. The real mess starts from here though: - Wayland can not render strings. You need something external just to render some other text than "hello world". And depending on the library text rendering will look different for each application. - Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely. - If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor.
- chlorion 3y ago
  To me these are all advantages, not disadvantages. Wayland is not X11 and doesn't want to be, it doesn't implement even a fraction of what X11 did and that is an intentional design choice! Wayland does not provide any graphics drawing primitives at all. It only sets up a handle to some shared memory and expects the client to do all drawing. I think the point here is that you shouldn't be using the display protocol to render text in the first place. If you want to draw text you use a library that is designed for that task rather than shoving that functionality into the compositor and into the Wayland protocol itself. >- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely. You don't have to use a thread to do this! You aren't forced to block and wait for the callbacks, you can implement your own event loop and check for messages when you want to! >- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor. I think it's good that clients can't capture the screen without permission, and I think using dbus for IPC is very reasonable, but I don't know anything about pipewire or the compatibility stuff. Also I think it's fair to not like some of these design choices for sure, but it would probably be better for people who like X11's design to continue to use X11 rather than trying to force Wayland into an X11 clone. X11 will be around for a very long time so I don't think anybody will be forced to stop using it any time soon, and people can pick it up if development stops!

djha-skin 3y ago

Not really that niche when you have a 4K laptop hooked up to the 1080p monitors that you were able to buy because it was on your own dime and you wanted to go the affordable route. Every time I do that on X, The only thing I can do is downscale my 4K laptop screen to 1440, I can't set a fractional scale for it while still preserving reasonable performance. And no one cares about standardization and development. They just want to use their blasted laptop. I don't know about any of that stuff, I just know Wayland works better out of the box.