12

I have a graphically intensive application that needs to be forwarded over X11. I spent some time researching X11 and its (in)efficiency, including this great post: Why is X11 forwarding so inefficient?.

One thing that's still not crystal clear to me is whether the performance of X11 forwarding depends on the application. I was under the impression that the whole screen is forwarded, no matter what's going on. Then X11 forwarding should be application-agnostic.

So, is there any concrete information on what actually gets forwarded and whether the performance of ssh -X depends on the application?

4
  • 2
    "So, is there any concrete information on what actually gets forwarded and whether the performance of ssh -X depends on the application?" Yes. As a start, see Daniel Stone's talk The Real Story Behind Wayland and X from LinuxConf.au 2013.
    – user11574
    Commented Feb 1, 2019 at 15:03
  • 1
    "I was under the impression that the whole screen is forwarded" It's hard to understand what would give you that impression, because what people usually do with SSH X forwarding is to manually run individual applications on the remote shell; could you maybe elaborate on how you are launching the applications?
    – rakslice
    Commented Feb 2, 2019 at 3:54
  • 1
    One factor of note if you're transporting the X session over an SSH tunnel: ssh can do compression. It's the -C option on the command line or the Compression: yes option in the .ssh/config file. If you're doing traditional X forwarding from Dallas to Australia over a congested T1 link, this can be the difference between having your task of bringing up a dialog five levels deep in the interface and selecting a checkbox from an unrealistic task to a merely exceedingly frustrating two hours. I've fortunately not had the need to try this with Wayland, but I assume it's greatly improved.
    – Ed Grimm
    Commented Feb 2, 2019 at 7:01
  • I don't want to start an extensive discussion in the comments, especially since my question has been answered very well by the @grawity. By "the whole screen" I meant that the data forwarded over the ssh tunnel would always be a simple description of pixels on the screen.@EdGrimm: Thank you for your comment about compression. I am aware of that. In our particular scenario, X11 is forwarded over a 10Gbit LAN Link and compression/no compression seems to make absolutely no difference.
    – Fang
    Commented Feb 2, 2019 at 7:53

1 Answer 1

30

I was under the impression that the whole screen is forwarded, no matter what's going on. Then X11 forwarding should be application-agnostic.

No, it's actually the opposite. The reason X11 forwarding is called "X11 forwarding" is because it transports the actual X protocol messages used by applications to render their windows on the "X server" (typically Xorg). Those messages are commands for creating/moving windows, drawing text and graphical primitives (lines/rectangles), drawing bitmaps, etc.

You could say it's conceptually the opposite of "full screen image" protocols such as VNC/RFB. I think it is somewhat comparable to Windows' RDP, which was also made for transporting GDI drawing commands.

So the reasons you see differences between programs are:

  1. To quote the post that you've referenced, originally most X-based programs worked like this:

    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.

    So when a program wanted to show a button, it just sent a few short commands – "draw a rectangle", "draw text", and perhaps some lines to make it look 3D.

  2. Over time this changed, programs started doing the rendering by themselves, and many of those instructions became just "here's a bitmap which I already rendered, put this on screen" – very fast locally, but very slow over the network due to X11 lacking any image compression.

    This means programs built using modern toolkits are much slower over networked X11, even if it's something as basic as antialiased fonts.

    (In contrast, RDP has adapted over time and includes various forms of image compression such as JPEG and even H.264; you can often notice the compression artifacts while the full image is loading.)

  3. Fortunately, most UI toolkits such as GTK implement damage tracking so only updated regions are re-sent. However, a few programs (such as several Firefox/Thunderbird versions), don't support this and request a complete re-render of the entire window, even if it hasn't really updated.

    That's another difference between programs – well-behaving ones are still quite usable over the network, but buggy ones can saturate a 100 Mbps link doing absolutely nothing useful.

3
  • 1
    I remember once trying to set up a MythTV server. The "setup" utility was a Qt application and took several minutes to display each page of configuration, despite a reasonable ADSL link as bottleneck (nearly 8 Mb/s). A few minutes' work took several hours because of this - it would have been so much easier with a Curses UI, or even a well-behaved X11 application. If I'd known how much trouble it was going to be, I'd have waited a week or two until I was on-site and used one of the diskless front-end boxes for display. I wanted the server up and working sooner than that, though. Commented Feb 1, 2019 at 14:33
  • 1
    In defense of those "buggy programs" one should point out that this is the fault of the X+toolkit ideology, which basically makes it necessary for those buggy programs to be buggy in the first place. You would think that a program could just call an API (which sends a command) to have a "normal looking window", a menu and a button here and a scrollbar there, but no. You, or the toolkit, must do everything by hand. I'm really no big fan of MS and even less so Apple, but they've got those things right whereas the X ecosystem has sucked for decades, and still sucks.
    – Damon
    Commented Feb 2, 2019 at 15:30
  • I'm not sure if there is any difference though. What makes Windows' UWP or WinForms or comctl32 less of a "toolkit" than GTK and QT? Don't they also do everything "by hand"? Commented Feb 2, 2019 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .