Some GUI applications do not play well with VNC due to a number of reasons. I use VNC on my LAN with no performance issue per se, but some applications are dogs under VNC, typically wxWidgets-based stuff can elicit various issues such as rendering performance and mouse cursor issues. Or directly GTK-based stuff as well (in particular GTK 3.)
One example is KiCad - absolutely horrific experience via VNC.
one can develop a def-io virtual framebuffer in kernel space readdressing TLB dirty events that collide on the framebuffer area on interrupts that shot packets on the ethernet, to make a kind of "remote framebuffer" kernel space protocol.
it works, but introduces latencies, and requires some form of compression, plus it's easy to implement stuff on the LLC layer, a bit more complex on the UDP layer, and much more complex on the TCP layer to the point you'd better use a "userspace helper", which eases your life but introduces more latency.
._______________ ___________
| | | |
| computer | | xterm |
| | | |
| _____RAM___ | | |
| | | | | hardware |
| |virtual | | |framebuffer|==== video
| |framebuffer| | ethernet | |
| | |=================== |
| |___________| | | |
| Kernel defio | | |
|_______________| |___________|
(Sonoko)
So, it's better to use the physical framebuffer and an external capture device that captures the video output, compresses it to the differences without loss, and sends it via the network (even better if optical network).
._____________ _______________
| | | |
| computer | | xterm |
| | | |
| | | ______RAM__ |
| | ______ | | | |
| hardware | | | | |virtual | |
| framebuffer |== video ==| grab |== lan ==| |framebuffer| |=== video
| | |______| | |___________| |
|_____________| |_______________|
(Zaphire)
Solves all the problems in a single shot!
Just ... the complexity goes outside your computer, and developing such equipment costs a lot of time and money.
Sonoko and Zaphire, are two of my projects