VNC is also much faster in most cases, because the X protocol requires a lot of round trips that waste a lot of time. So instead the VNC server "runs these round-trips locally" (so to speak) and you only interact with the pixels remotely. X was developed when bandwidth was as limiting as latency but nowadays only latency is limiting so a different protocol makes more sense.
You can't pipeline X11 operations in the presence of anything but a perfect network because
1. TCP streams require stalling when packets are dropped to keep the stream in order
2. X _requires_ by design that commands are performed in order
Which means that using something that can do UDP and manages it's own sequence ordering can do significantly better. This is why things like RDP, PCoIP, etc could do full frame rate HD video 15 years ago and you still can't with X protocol over the network.
Breaking up the screen into small 16x16 chunks or so, encoding on the GPU, and shipping that turns out to be significantly faster.
Especially when you take into account that virtually _nothing_ draws with X using X drawing primitives. It's almost all using Xshm for anything non-trivial.
Most modern Ethernet LANs are effectively lossless. You're not going to see a single dropped packet unless you saturate the link.
> Which means that using something that can do UDP and manages it's own sequence ordering can do significantly better. This is why things like RDP, PCoIP, etc could do full frame rate HD video 15 years
No it isn't. It's because those things actually compress the video, and X-forwarding generally doesn't. The transport protocol is completely irrelevant, it's just a bandwidth problem.
I've X-forwarded Firefox between two desktops on 10G Ethernet. I can watch 4K video, and I genuinely can't tell the difference between local and remote.
If you're including TCP ACKs as part of the "chatty"/"required round trips" of a higher level protocol, that's bad new for a lot of things. (Which, granted, is why they made those QUIC protocols etc., but still, it seems unreasonable to single out X's protocol for this, especially since RDP and VNC are commonly used over TCP as well).
But:
> This is why things like RDP, PCoIP, etc could do full frame rate HD video 15 years ago and you still can't with X protocol over the network.
Compression is going to have a much bigger impact over a large motion than most anything else; you can stream video over HTTP 1.1 / TCP thanks to video codecs, but X (sadly i think, seems like such an easy thing that should have been in an extension, but even png or jpeg never made it in) doesn't support any of that.
> It's almost all using Xshm for anything non-trivial.
Xshm is not available over a network link and it is common for client applications to detect this and gracefully degrade.
VNC hasn’t always been that good though. There was a time when I’d routinely use X forwarding via SSH because my (then) girlfriends internet connection wasn’t fast enough to run VNC smoothly.
different implementations of vnc support different compression algorithms and for some reason vnc always defaults to the worst (most compatible?!?) ones.
You can achieve a lot by tweaking the client and server settings.
The results were good enought for me to support customer with ISDN internet between 2001-2006.
or you are like me and remote-desktop from a thin client (or from home) to a windows VDI, run vnc to a X server and ssh -X to the dev box to run emacs (edit: and firefox). I do this every day and I'm amazed that it actually works smoothly.
