Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. Windows is using it since Vista. When done right, gradients mentioned in other comments are free, GPUs have hardware to interpolate values (such as colors) across vertices of triangle, for free. Many other effects are either free or very cheap.
Engineering-wise it's really hard.
Microsoft reworked GPU driver model introducing WDDM. They invented a new user-facing API for that, introducing Direct3D 10. They did that in close collaboration with all 3 GPU vendors. They made user-mode components like desktop compositor itself, dwm.exe, and higher-level libraries to benefit from all that stuff. Initially they were optional things like WPF, Direct2D, DirectWrite, then with Win8 they introduced WinRT later rebranded to UWP. That one is no longer optional and is the only practical way to render "hello world, GUI edition" in modern Windows (possible to do with DirectWrite or legacy GDI but neither of them is practical).
The problem "render nice high-resolution graphics, fast" affects everything, the entire stack. Modern Linux has decent kernel infrastructure (DRM/KMS), but even so, remaining challenges are hard. Linux has less luck with user-facing GPU APIs (Vulkan is not yet universally available, neither is GLES3+ or OpenGL 4.3+). For some GPUs, quality of drivers is less than ideal. OS maintainers oppose stabilizing kernel ABI for drivers. There's no high level GPU-centric graphics libraries, I tried once with moderate success https://github.com/Const-me/Vrmac but that only supports one specific Debian Linux on one specific computer which happens to support GLES 3.1, and some important features are missing e.g. no gradient brushes or stroked pens.
I don't see any large party interested in making that happen. At least not for desktop Linux. Valve started to do relevant things when they thought Windows 10 is going to kill their Steam business model, then it became apparent Microsoft won't make Win10 into an iOS-style walled garden, and they no longer have much motivation.
> Technically what Wayland is doing, using 3D GPU for everything, is the best way forward.
It's great for the common desktop case.
It's not as great for some other cases in which Linux is the preferred platform (headless servers, repurposed old hardware, etc).
The problem isn't, of course, that there exists a solution for this on Linux. It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.
Also phones and tablets. Also embedded devices who have a GPU + LCD, I have personally shipped Linux firmware where I used NanoVG on top of DRM/KMS to render touch screen GUI. Also for kiosks, cars, smart watches and many other applications.
It’s great everywhere you have a high-resolution screen. And it’s mission-critical for ARM devices who don’t have CPU power to render that screen on CPU, at least not at 60Hz.
> headless servers
Why would you want a GUI there? Even Microsoft has console-only “core” editions of their Windows Server, since 2008. They made it because competition from Linux, who had that from the very beginning and was thus way more suitable for cloud use cases. It still is due to other reasons, but that’s another story.
> It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.
I get why some people would want the X to be maintained, but the thing is, it’s very expensive, and not fun.
Developing game console emulators is expensive, but fun and people do that in their free time with great results. Moving forward GPU-targeted Linux GUI is expensive, not too fun, but there’re commercial applications with healthy profit margins (automotive, embedded, etc) so people from these areas are working on that tech. Patching x.org for repurposed old hardware, on the other hand…
Wayland’s mistake is assuming every application has a local GPU. In reality the user has just one GPU attached to his monitor, which is fine for email and gaming, but serious tools run miles away in datacenters. We wouldn’t be rewriting everything in javascript if only we hadn’t forgotten how cool remote X was.
I work on a serious tool, specifically it’s CAM/CAE stuff. Despite Google, Amazon and MS sales people apply pressure to upper management (they want us to move to their clouds and offering gazillions of free compute credits), our software works on desktops and workstations, and I have reasons to believe it gonna stay this way. With recent progress of HPC-targeted CPUs, and steady downward trend of RAM prices, I believe our customers are happier running our software on their own computers, as opposed to someone else’s computers.
> We wouldn’t be rewriting everything in javascript if only we hadn’t forgotten how cool remote X was.
It was cool in the epoch of OpenGL 2. By the time Metal, Direct3D 12, and finally Vulkan arrived, it stopped being cool. Essentially, these APIs were designed to allow apps to saturate PCIe. You can’t transfer that bandwidth over any reasonable network.
Engineering-wise it's really hard.
Microsoft reworked GPU driver model introducing WDDM. They invented a new user-facing API for that, introducing Direct3D 10. They did that in close collaboration with all 3 GPU vendors. They made user-mode components like desktop compositor itself, dwm.exe, and higher-level libraries to benefit from all that stuff. Initially they were optional things like WPF, Direct2D, DirectWrite, then with Win8 they introduced WinRT later rebranded to UWP. That one is no longer optional and is the only practical way to render "hello world, GUI edition" in modern Windows (possible to do with DirectWrite or legacy GDI but neither of them is practical).
The problem "render nice high-resolution graphics, fast" affects everything, the entire stack. Modern Linux has decent kernel infrastructure (DRM/KMS), but even so, remaining challenges are hard. Linux has less luck with user-facing GPU APIs (Vulkan is not yet universally available, neither is GLES3+ or OpenGL 4.3+). For some GPUs, quality of drivers is less than ideal. OS maintainers oppose stabilizing kernel ABI for drivers. There's no high level GPU-centric graphics libraries, I tried once with moderate success https://github.com/Const-me/Vrmac but that only supports one specific Debian Linux on one specific computer which happens to support GLES 3.1, and some important features are missing e.g. no gradient brushes or stroked pens.
I don't see any large party interested in making that happen. At least not for desktop Linux. Valve started to do relevant things when they thought Windows 10 is going to kill their Steam business model, then it became apparent Microsoft won't make Win10 into an iOS-style walled garden, and they no longer have much motivation.