3 ms·

Are We Wayland Yet?

4 points by varbhat 6y ago

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
maltalex 6y ago
"Mostly" is correct, but some of the problems with Wayland are fundamental and will never be fixed. From "Major Linux Problems on the Desktop, 2020 edition"[0]: - Applications (or GUI toolkits) must implement their own font antialiasing - there's no API for setting system-wide font rendering. Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X. In Wayland all clients (read applications) are totally independent. - Applications (or GUI toolkits) must implement their own DPI scaling. The above issues are actually the result of not having one unified graphical toolkit/API (and Wayland developers will not implement it). Alas, no one is currently working towards making existing toolkits share one common configuration for setting font antialiasing, DPI scaling and windows shadowing. At least in theory these issues can be easily solved, in practice we already have three independent toolkits for Wayland (GTK3/Qt5/Enlightenment). - Wayland works through rasterization of pixels which brings about two very bad critical problems which will never be solved: Firstly, forget about performance/bandwidth efficient RDP protocol (it's already implemented but it works by sending the updates of large chunks of the screen, i.e. a lot like old highly inefficient VNC), forget about OpenGL pass-through, forget about raw compressed video pass-through. In case you're interested all these features work in Microsoft's RDP. Secondly, forget about proper output rotation/scaling/ratio change. [0]:https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html https://itvision.altervista.org/why.linux.is.not.ready.for.t...
- cycloptic 6y ago
  A lot of information in that article is outdated or just wrong. >Applications (or GUI toolkits) must implement their own font antialiasing This is wrong. Nearly everything uses freetype, and fontconfig has settings for how freetype should render fonts. If your app is not honoring these settings that's a different problem. >Applications (or GUI toolkits) must implement their own DPI scaling. In practice, implementing DPI scaling is trivial for applications that use a canvas. It only becomes a problem if your application renders raw pixels. If you're sending pixels and don't account for DPI scaling then you get a blurry window upscaled with nearest neighbor. That's how it works on windows and mac too, try running a non-DPI-aware application there and you'll see the same thing. It has nothing to do with the windowing system or the toolkit. >forget about OpenGL pass-through, forget about raw compressed video pass-through ... forget about proper output rotation/scaling/ratio change That won't ever be solved in Wayland because Wayland explicitly doesn't touch any of that. That's not to say they won't ever be solved: those things can be added but they probably need to happen at a different level of the stack.

Are We Wayland Yet?

4 points by varbhat 6y ago

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

maltalex 6y ago

"Mostly" is correct, but some of the problems with Wayland are fundamental and will never be fixed. From "Major Linux Problems on the Desktop, 2020 edition"[0]: - Applications (or GUI toolkits) must implement their own font antialiasing - there's no API for setting system-wide font rendering. Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X. In Wayland all clients (read applications) are totally independent. - Applications (or GUI toolkits) must implement their own DPI scaling. The above issues are actually the result of not having one unified graphical toolkit/API (and Wayland developers will not implement it). Alas, no one is currently working towards making existing toolkits share one common configuration for setting font antialiasing, DPI scaling and windows shadowing. At least in theory these issues can be easily solved, in practice we already have three independent toolkits for Wayland (GTK3/Qt5/Enlightenment). - Wayland works through rasterization of pixels which brings about two very bad critical problems which will never be solved: Firstly, forget about performance/bandwidth efficient RDP protocol (it's already implemented but it works by sending the updates of large chunks of the screen, i.e. a lot like old highly inefficient VNC), forget about OpenGL pass-through, forget about raw compressed video pass-through. In case you're interested all these features work in Microsoft's RDP. Secondly, forget about proper output rotation/scaling/ratio change. [0]:https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html https://itvision.altervista.org/why.linux.is.not.ready.for.t...

cycloptic 6y ago
A lot of information in that article is outdated or just wrong. >Applications (or GUI toolkits) must implement their own font antialiasing This is wrong. Nearly everything uses freetype, and fontconfig has settings for how freetype should render fonts. If your app is not honoring these settings that's a different problem. >Applications (or GUI toolkits) must implement their own DPI scaling. In practice, implementing DPI scaling is trivial for applications that use a canvas. It only becomes a problem if your application renders raw pixels. If you're sending pixels and don't account for DPI scaling then you get a blurry window upscaled with nearest neighbor. That's how it works on windows and mac too, try running a non-DPI-aware application there and you'll see the same thing. It has nothing to do with the windowing system or the toolkit. >forget about OpenGL pass-through, forget about raw compressed video pass-through ... forget about proper output rotation/scaling/ratio change That won't ever be solved in Wayland because Wayland explicitly doesn't touch any of that. That's not to say they won't ever be solved: those things can be added but they probably need to happen at a different level of the stack.