Fastest remote X from Windows

I think the state of the art for the maximum bandwidth is NX, an X11 protocol compression program. It should perform well with respect to latency too. Try using the Windows NX client and the free NX server on Linux.

If possible, use a direct TCP connection instead of SSH. Of course, this is only viable in a controlled environment with no security worries.

I think in most setups a virtual machine running locally will give you the best latency. Even better, run Emacs and Eclipse under Windows; make them edit remote files, or (for even better results) make them edit local files which you then synchronize with Unison or through a version control system.

Windows Remote Desktop works just fine -- as long as you run xrdp on the Linux box (and in my experience, it is significantly less annoying and more responsive than VNC).

xrdp runs an X server on the Linux box, and then hooks that up to RDP.

In fact, even though I usually have Linux on both ends of this wire, I typically prefer rdesktop to xrdp over VNC whenever plain X11 forwarding proves too sluggish. VNC is just a French acronym for "doesn't work very well".

I agree that Mobaxterm is fast in x forwarding. Then I find out that it's using ssh based on cygwin, but it's still faster than my cygwin/ssh. After looking into debug info, I find out the secret of Mobaxterm is using aes128-ctr rather than the more common aes256-cbc cipher, use hmac-sha1 and turn on compression by default.

In cygwin,

ssh -m hmac-sha1 -c aes128-ctr -C 

should give you performance close to mobaxterm. If you still believe mobaxterm is faster, you can directly use _ssh.exe, which you can find in your mobaxterm root.

Some blogs/answers suggested ciphers like arcfour or blowfish. They should be slightly better than aes128-ctr (for old CPU), but they are outdated and not necessarily available on all platform. You can view all supported ciphers and macs by

ssh -Q cipher
ssh -Q mac

This benchmark shows that aes128-gcm should give you the best performance on modern CPU.

Update:

Some suggest against compression. I would say assume -C still helps unless your trial turns out otherwise, even if you believe your network is perfect. Since the data transfer amount is very huge, and the compression ratio is impressive, e.g.

 debug1: compress outgoing: raw data 603154, compressed 141717, factor 0.23 
 debug1: compress incoming: raw data 67841628, compressed 641357, factor 0.01

Actually, I tried x forwarding with both direct tcp and ssh with compression and an appropriate cipher over an internal 100Mbps LAN connection with <1ms latency. The ssh option is obviously faster.