The old core protocol approach extensively used optimized graphic operations on the server side, with clients sending things like "draw me a rectangle/fill a rectangle/draw a bunch of lines" etc. - today you're going to get pretty big bitmap (especially with high dpi).
It's the same problem that mobile devices faced, and is related to a lot of issues on how android devices were "janky" (and related to the various hacks that Apple did to make sure your application wasn't capable of overstressing the early iPhones - cause just displaying basic UI was close to doing that.)
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.
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…
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.
Abstractions piled on top of abstractions. Something that might have been 5 function calls deep on either side with a carefully crafted packet in the middle is now 100s on each side.
We have a culture that prizes programmer happiness above all and this means everyone thinks "this is a mess, I'll put my own layer on top to make it nice, then work above that layer". Repeat 100 times and now you have processors literally 2000 times faster that struggle to even keep up with keypresses. But what noone wants to admit, is that it's messy because the problem domain is messy and sometimes you just have to live with the mess and get some real work done. The programmers of old understood this.