Two hosts on the same LAN can have excellent performance with VNC. There are some things you need to know and some work you need to do, however.
First, the two most common DEs, Gnome and KDE, use X compositing by default. This is very bad for VNC. You want to turn that off. Unfortunately you can't with Gnome, which is sad. You can turn off compositing in KDE, and that's one reason I've preferred KDE for years. Other DEs can also forego compositing.
Second, turn off all encryption between the VNC client and server. No SSH-ing, no build-in VNC encryption. Nothing. Ignore the nag warning about the lack of encryption some VNC clients hit you with.
Third, no VNC compression. You're on a LAN and you don't need it or the lag it adds.
Forth, don't "share" the VNC session with the remote host's desktop. Use the vncserver headless X server. Every "shared" VNC system (where the desktop appears both local and remote) I've encountered is laggy.
Fifth, use a fast VNC client. RealVNC's VNC Viewer is excellent.
Sixth, do not scale. Ensure your vncserver's resolution matches your VNC's client size exactly.
Seventh, tune your DE to remove whatever animations or alpha effects exist.
Eighth, no wifi. Ethernet only between VNC server and client. Wifi is awful for this.
Ninth, use decent ethernet gear. Some NICs are low end and impose more latency. Likewise, low cost switches are bad news as well.
Do these things and your VNC session will be difficult to distinguish from a local DE. If you're using gigabit or faster LAN you'll be able to play video through VNC reasonably well.
I agree. RDP and Windows are light years ahead of Linux here. This is just my take on this for a local LAN environment, and if that's your use case and you follow my guidance you'll be pleased with the result.
One benefit of using VNC is the lack of glitches. I've been down every road; nomachine, various commercial and open source X servers, xrdp, all of it. They all have glitches; sizing problems, decoration problems, font problems, keyboard state problems, pointer problems, you name it. VNC (operated as I've described above) doesn't; everything is correct, all of the time.
Other than the compositing thing, which I have not encountered, I disagree with all this advice.
I've had good luck with tigervnc in the past. My raspberry pi 4 had trouble pulling 4k video, but whatever.
Most of the vnc latency comes from unoptimized compression (like not using SSE for jpeg, etc), or poor default settings.
There are also remote desktop protocols that rely on GPU accelerated compression (mostly for gaming and 3d work). Those are mostly fine for light 3d shooters, etc. Sometimes I even watch YouTube videos over them with a 10-20mbit, 40ms internet connection. (I didn't bother measuring network usage for that; 20mbit is an upper bound.)
Hell of a lot of limitations to do it right in 2022.
Is compression really bad? In instances like file system, sometimes it may even be faster to enable compression as disk IO is slower than computational time.
And you're telling we need desktop to desktop to make it work good and what kind of NIC can't handle enough bandwidth for VNC? You sound like we're playing a next gen VR game.
> Is compression really bad? In instances like file system, sometimes it may even be faster to enable compression as disk IO is slower than computational time.
Compression noticeably adds latency. You see that easily when scrolling windows; it's not difficult to detect at all. The intent is to get minimum latency; I use these remote DEs all day and latency creates fatigue. If you're truly remote with limited bandwidth then compression will clearly have value.
> and what kind of NIC can't handle enough bandwidth for VNC
Today, integrated NICs are great, but not long ago some of these were poor and roundtrip latency was as high as 100 us or more. I could see the difference just holding the space bar and watching a terminal cursor move. If you really want a nice experience use a decent NIC; nothing crazy, just not low end integrated stuff that's barely more than a PHY and relies almost entirely on the CPU.
Latency is the thing I've worked to reduce so my remote desktops feel as local as possible. Every incremental change I've made has been noticeable; 2.5Gb/s is slightly better than 1 Gb/s when playing video, for example; something I noticed recently after upgrading the NIC on one remote host.
I don’t know the details of how a VNC program work, but I would be surprised if encryption would measurably change anything - at least on a file system level it doesn’t make a difference, due to out-of-order execution - it easily fits in the “waits” for IO.
First, the two most common DEs, Gnome and KDE, use X compositing by default. This is very bad for VNC. You want to turn that off. Unfortunately you can't with Gnome, which is sad. You can turn off compositing in KDE, and that's one reason I've preferred KDE for years. Other DEs can also forego compositing.
Second, turn off all encryption between the VNC client and server. No SSH-ing, no build-in VNC encryption. Nothing. Ignore the nag warning about the lack of encryption some VNC clients hit you with.
Third, no VNC compression. You're on a LAN and you don't need it or the lag it adds.
Forth, don't "share" the VNC session with the remote host's desktop. Use the vncserver headless X server. Every "shared" VNC system (where the desktop appears both local and remote) I've encountered is laggy.
Fifth, use a fast VNC client. RealVNC's VNC Viewer is excellent.
Sixth, do not scale. Ensure your vncserver's resolution matches your VNC's client size exactly.
Seventh, tune your DE to remove whatever animations or alpha effects exist.
Eighth, no wifi. Ethernet only between VNC server and client. Wifi is awful for this.
Ninth, use decent ethernet gear. Some NICs are low end and impose more latency. Likewise, low cost switches are bad news as well.
Do these things and your VNC session will be difficult to distinguish from a local DE. If you're using gigabit or faster LAN you'll be able to play video through VNC reasonably well.