It's a completely unsubstantiative argument; its effect is to sweep under the rug any justification for the 'old way' of doing things.
For one very big thing, hardware accelerated rendering didn't exist in 1980.
Also, no one really cares about network support anymore, because it's simpler and better to just do a screen share.
I care about network support for GUI applications.
I don't think _whole screen_ shares are either simpler or better.
Give it a try and let us know.
Actually, some of us do make use of X11 network transparency on a regular basis. Running an X11 program on a remote CPU, but having its window appear on the screen of the machine I'm sitting in front of, is quite a useful feature. And one that I make use of quite regularly. And it is most definitely not the same as a 'screen share'.
> Is Wayland network transparent / does it support remote rendering?
> No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
Note that the next two paragraphs do discuss how network transparency could be built, by clients, on top of Wayland.
So it depends on how you define "does wayland break X-forwarding":
If defined as Wayland, the new server, yes. Because network transparency is not built in to Wayland the new server.
If defined as Wayland, the ecosystem, well, there appear to be ways to do it by adding it back in.
ssh -X still works and wayland native is waypipe ssh (though one could probably wrap that into ssh -X to make it seamless).
[citation needed]
Let me guess, you live in a city?
On the other hand xlib toolkits like xathena widgets run blazingly fast even over modem style connections because all the drwaing happens server side and only a limited amount of drawing commands are transmitted over the network.
Then why the hell isn't it being used by GTK/Cairo nor Qt in production code. Oh yes, there are OpenGL(-ES) backends in both. But by far and large they're doing all their rendering on the CPU and then blit over to the graphics system. This is BTW the main reason for Wayland coming to be in the first place: The observation that the X server has been "reduced to a blitting engine" (if your world view is so narrow to cover only GTK and Qt).
And then they're draining the baby with the bathwater… Wayland is how old now, 9 to 10 years, and it's still far from usable for production. IF you compare that with X11, after 10 years it didn't have just a barely working server and some example application. It was a thriving ecosystem with multiple desktop environments, toolkits, loads of production applications and you could just run them all arbitrarily in the same environment.
Only last Friday I was working on a custom windowing library (something in the same vein as GLUT, SDL or GLFW, however with a focus on "desktop" programs with traditional GUIs instead of things like games) and whenever I start working with the Wayland side of things it turns into a severe headache. Wayland is an actively developer hostile (and I'd even wager to say user hostile, too) ecosystem. For example, because in Wayland there's no concept of windows, and whatever a window is, is left to the compositor, you can't even properly implement something like dockable windows. The best hack I could come up with was via the drag'n'drop mechanism that Wayland then does specify.
IMHO Wayland is a prime example for the sunken cost fallacy hitting hard.
I've used that feature every single day for the last 20 years.
Take for instance a big 3D game. It is much more bandwidth-efficient to compress the frames and send that over than to send the 3D models, textures and transformation matrices over the net. We still don't have PCIE Gen. 4 bandwidth for networking.
Okay, this is an extreme example. But most apps (just take Firefox as an example) send bitmaps over X forwarding anyways. I use Xpra for these, but waypipe should work a lot better, in theory (less round-trips, etc). Of course, it's better if the graphics toolkit is install at both ends and can render the stuff locally (which was the intent with X). AFAIK a few support that, I wonder if rdp doesn't specify something to negotiate its use on a per-client basis?
The GP was suggesting “without extensions”. Good luck with that.
(I also think modern fonts don't look nice; I want to use bitmap fonts on the screen!)