The X11 protocol was never meant to handle graphically (in terms of bitmaps/textures) intensive operations. Back in the day when X11 was first designed computer graphics were a lot simpler than they are today.
Basically X11 doesn't send the screen to your computer, but it sends the display-instructions so the X-server on your local computer can re-create the screen on your local system. And this needs to be done on each change/refresh of the display.
So your computer receives a stream of instructions like "draw line in this color from coordinates x,y to (xx,yy), draw rectangle W pixels wide, H pixels high with upper-left corner at (x,y), etc."
The local client isn't really aware what needs to be updated and the remote system has very little information on what the client actually needs, so basically the server must send a lot of redundant information that the client may or may not need.
This is very efficient if the display to be rendered consists of a limited number of simple graphical shapes and only a low refresh frequency (no animations and such) is needed. Which was the case back in the days when X11 was first developed.
But modern GUI's have a lot of eye-candy and much of that needs to be send from the remote system to your client in the form of bitmaps/textures/fonts which take quite a lot of bandwidth. And all sorts of eye-candy includes animated effects requiring frequent updates. And the displays keep getting bigger too, twice as wide/high is 4x the number of pixels.
Of course, over time, enhancements to the X11 protocol were made to optimize this as much as possible, but the basic underlying design is, in essence, simply not well suited to the demands of the kind of GUI's people nowadays expect.
Other protocols (like RDP and VNC) are more designed to let the remote system do all the hard work and let that system decide which updates to send to the client (as compressed bitmaps) as efficiently as possible. Often that turns out to be more efficient for modern GUI's.
Neither method is perfect and can deal with every situation equally well. There is no such thing as a single display-protocol that can do well under every conceivable use-case.
So in most cases you just try all protocols that are supported between your local client and the remote server and use the one that gives the best results. And in some cases there is no choice and you just have to make do with whatever is available.
Most protocols do allow some performance tuning, but many of these settings are server-side only and not available to the average user. (And configuring them properly is a bit of an arcane art. A lot of sys-admins won't be willing to mess with that.)
In most cases the easiest way to improve performance (sometimes quite dramatically) is by switching to a more simple desktop environment with less eye-candy and forego the use of background images.
9
Trivia: Xpra offers an interesting approach.
– Kamil Maciorowski – 2017-06-08T15:10:48.86312BTW -- using "-C" will slow down your connection if your link is fast enough because compression takes time. "-C" might benefit 100Mb, but likely harm 1Gb, and certainly harm 10Gb. It's also the case that 'ssh' will harm your throughput -- as will any encryption over fast links. If you have a direct-connection between computers or a secure internal-linkage, go direct with your X connection over TCP:6000. You'll get a noticeable speed improvement. – Astara – 2017-06-09T03:03:29.760
2Sounds like you're forwarding through SSH, which has to encrypt / decrypt all of the data. That's going to add overhead / latency. Faster processors might help, but there's a certain amount of latency this will add, no matter WHAT you do. X is very "chatty," so slight increase in latency = significant drop in performance. In times past, I was able to use X, tunneled through SSH over a 28.8 modem; that was using lbxproxy (now deprecated) which cached / compressed a lot of data and reduced the "chattiness" of the connection. Using -C can only add more latency. – Meower68 – 2017-06-09T20:41:56.947
Use something like
ssh -Y -c blowfish
to minimalize overhead while still encrypting. If you have full control of both ends teach ssh to use "none" encryption to get full transfer speed on the connection. – Thorbjørn Ravn Andersen – 2017-06-10T17:46:13.483