The main killer feature for me is how easy it is to run graphical applications over the network using X.
I run a FreeBSD desktop with virtualized Linux, OpenBSD and Windows systems. the ability to run applications like they are on the host system is something I have not yet seen how to do with Wayland.
Well to my surprise, waypipe seems to be faster, especially when it comes to input latency and such.
I assumed it was a bit slow because of the long startup lag; but it seems it's mostly because of my slow (WiFi) network, and is even worse with X forwarding.
I just tried opening the same (simple) application through waypipe and through X forwarding, and using waypipe it's actually a lot more usable.
While it's a cute idea, I doubt this feature of X has serious support behind, and I don't think any future graphics system, be it Wayland or something else, will support it. Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream.
Sending rendering commands over a network is only decently fast if you have simple windows and no pictures. As soon as you want anyhting fancier, even as simple as opening a high res photo, the video streaming approach becomes significantly better.
X's model can have one advantage, when the machine running the X client doesn't have rendering resources locally at all (so that local rendering + video streaming would take too long for the CPU, despite the network advantage). But that is an even rarer use case.
>Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream.
The RDP protocol also sends graphics commands (mostly). It works really well on Linux with Xrdp/rdesktop. The idea of sending a video stream over network sounds good but somehow the implementations always manage to screw it up (especially on high bandwidth networks). I just did a quick test by directly streaming video over WLAN and it performed way better that VNC. I was able to stream a videogame smoothly on 30FPS, which is pretty impressive considering this was done in a very unoptimized way (netcat, TCP instead of UDP, etc.)
I always found rdp on Linux far easier to use than all that X11 network stuff. I think it was a neat idea to have it built-in, but also never quite worked all that smoothly in my experience and really does complicate things quite a lot. Sometimes the practicalities of neat ideas don't really work out unfortunately.
To be honest it's been quite a while, so you'll have to forgive me if I don't recall the specifics, but rdp was essentially "I start daemon, I run rdp [dst]", and it works", whereas Xorg involved a lot more mucking about with commands and reading manpages and whatnot.
I will admit that in part this was just my ignorance; I just used it to access my desktop on occasion from my laptop on the sofa and didn't really want to spend a lot of time on it. rdp was "it works out of the box effort-free and I can move on with my life" and X11 wasn't. Maybe I just didn't RTFM hard enough, but I didn't have to RTF anything for rdp, so...
I use samba/SMB for similar reasons by the way; recently I wanted to setup a network drive (for the first time in about 10 years) and samba provided a much smoother "just works" type of experience than NFS. Sometimes I find the old-type Unix stuff a bit painful, especially for the "just want to get shit done" type of workflow (I did use NFS extensively with FreeBSD and NetBSD back in the day, but it seems I've forgotten almost everything).
Huh, interesting. I made that conclusion based on how I see objects loading, with sharp outlines appearing before other elements. Also, some programs which draw their UI in a specific way become very slow, presumably due to some kind of graphics sync, something that I wouldn't expect from a video based protocol.
Even on X11 almost nothing sends server-side rendering command anymore. Almost every recent application (save for suckless stuff) renders cliends side, which means that if the x server is forwarded over the network every frame is a bitmap download.
It's an extremely inefficient way of doing things and it should have improved upon but wayland choice to just discard this use case was, imo, extremely narrowminded.
That's not as true a you may think. While Gtk+ and browsers do render everything locally using OpenGL and what not, Qt has these days a way to fallback to just sending simple rendering commands over the wire, and most other toolkits do use render commands too. Admittedly for a lot of desktop users "browser" covers 100% of what they do with the desktop, but for many professional/industrial users does not.
> I don't think any future graphics system, be it Wayland or something else, will support it
Which is another reason xorg isn't going to disappear, since large labs absolutely need computer A to display a resource-intensive program running on more-powerful computer B
The X protocol is only really necessary for the opposite case - for allowing powerful computer A to render the display of a weak computer B. If B is powerful, it can render the display itself and send the rendered images, as I was mentioning earlier.
The idea was I sign in to my underpowered workstation and run spice (or whatever) on the more powerful server. I would like the outputs to display on my weak computer. That's the whole point of this, and labs still use it religiously.
That “the network is slow” is not something I am willing to accept and go to great lengths to make sure it doesn’t happen. Which is why I run a virtualized Linux(with PCI pass thru)for max wifi performance and have a 10Gbit internet pipe at home.
Besides, we are talking local virtual machines in my case. Any performance issues so far has been negligible.
> While it's a cute idea, I doubt this feature of X has serious support behind, and I don't think any future graphics system, be it Wayland or something else, will support it. Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream.
I totally disagree. Obviously it just depends on your use case, but most user interfaces are almost completely static and sending vector commands is going to be a win over raster in almost any condition. Low bandwidth? Vector wins. High RTT link? Vector wins. Dual 4k screen? Not a problem with vector, but difficult with video and disastrous with raster.
One may argue whether the current implementation in Xorg is useful or not, but conceptually, I see vector as definitely the way to go. Vector even allows you to do some predictive interpolation, while raster -- good luck.
Maybe sending HTML+javascript over the wire is the solution, ala Display PostScript except more fashionable these days. Thinking about it, one could argue that's exactly what we have these days with the web...
If your UI is basically static, your video stream will also be low bandwidth.
Sending vector commands only makes sense if you have simple vectors. That isn't the case for modern apps and can't be the case for many kinds of apps.
Have you tried modern remote desktop solutions, like Parsec? Streaming 4K games or CAD works quite well, latency is about 20ms over the internet, low enough for most things.
The main killer feature for me is how easy it is to run graphical applications over the network using X. I run a FreeBSD desktop with virtualized Linux, OpenBSD and Windows systems. the ability to run applications like they are on the host system is something I have not yet seen how to do with Wayland.