https://www.scm.com/doc/Installation/Remote_GUI.html > OpenGL with X11 can run in two different modes: direct rendering and indirect rendering. The difference between them is that indirect rendering uses the GLX protocol to relay the OpenGL commands from the program to the hardware, which limits OpenGL capabilities to OpenGL 1.4. My naive understanding: When using X over the network (X11 forwarding), you can choose between two GLX modes: Direct Rendering on the remote computer you are accessing, or Indirect Rendering on your computer by transmitting GLX commands over the network. Indirect rendering supports OpenGL 1.4 at maximum, and Firefox anyway wants to move to EGL (bug 788319). WebRender requests GLX with OpenGL 3.2 or EGL with OpenGL 3.1, so in any case direct rendering (or software rendering) has to be used and the end result be uploaded over the network. From reading on Bugzilla, XRender seems to help with scroll performance of such previously painted Basic compositor tiles(??). WebRender doesn't have such tiles by default and it seems the external compositor trait couldn't be implemented for X11 as you can't composite all surfaces "with a single atomtic transaction" (bug 1617498 comment 0). Regular remote desktop tools use video codecs, but X seems to transmit in raw or when using SSH compression (`-C`) still half the size of raw.(?) https://stackoverflow.com/questions/12977879/ssh-compression-for-x11-forwarding > X11 graphics take up a lot of bandwidth. If your remote host is some distance away (i.e. not on the LAN), then you'll probably suffer sluggishness in your exported X11 applications. > Instead of interacting with the GUI using X11 forwarding, consider something else that has better optimization/compression, such as VNC or NX/FreeNX. > Actually well written X11 programs don't comsume a lot of bandwidth. The main issue with X11 is the abysmal badly written Xlib which performs a full synchronous roundtrip for almost every operation, while many operations could be performed asynchronously. If using another X11 protocol backend, like Xcb and not doing moronic things like rasterizing the whole GUI on the client and then just blitting the damn thing over the network, plain X11 over TCP over a low bandwidth, high latency connection is actually very usable. However many programs are written badly. https://superuser.com/questions/1217280/why-is-x11-forwarding-so-inefficient > X11, by default, doesn't do any compression on the network data that gets passed between the application and the display server. As you mentioned, you can use the -C option on SSH to enable compression, and while this does help, it's not optimized for compressing graphical data. Compared to formats like H.264 which can obtain compression rates of 100 to 1, the -C compression will be lucky to achieve 2 to 1 compression. A better solution is to use a graphics or video optimized codec for the X11 video, but we have to be careful not to make it too lossy as desktops generally need to have sharper images than a movie so the user can still clearly read the text and make out fine details. https://unix.stackexchange.com/questions/286691/more-efficient-x-forwarding https://superuser.com/questions/1400952/x11-forwarding-and-efficiency > 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. To 3: Partial present seems to work with Basic. Was it broken in February 2019 or just not enough in regard to scroll performance? Anyway, if users choose X11 forwarding, they consciously or unconsciously prefer a technically bad solution over more performant and more secure ones (regular remote desktop solutions).
Bug 1129492 Comment 32 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
https://www.scm.com/doc/Installation/Remote_GUI.html > OpenGL with X11 can run in two different modes: direct rendering and indirect rendering. The difference between them is that indirect rendering uses the GLX protocol to relay the OpenGL commands from the program to the hardware, which limits OpenGL capabilities to OpenGL 1.4. My naive understanding: When using X over the network (X11 forwarding), you can choose between two GLX modes: Direct Rendering on the remote computer you are accessing, or Indirect Rendering on your computer by transmitting GLX commands over the network. Indirect rendering supports OpenGL 1.4 at maximum, and Firefox anyway wants to move to EGL (bug 788319). WebRender requests GLX with OpenGL 3.2 or EGL with OpenGL 3.1, so in any case direct rendering (or software rendering) has to be used and the end result be uploaded over the network. From reading on Bugzilla, XRender seems to help with scroll performance of such previously painted Basic compositor tiles(??). WebRender doesn't have such tiles by default and it seems the external compositor trait couldn't be implemented for X11 as you can't composite all surfaces "with a single atomic transaction" (bug 1617498 comment 0). Regular remote desktop tools use video codecs, but X seems to transmit in raw or when using SSH compression (`-C`) still half the size of raw.(?) https://stackoverflow.com/questions/12977879/ssh-compression-for-x11-forwarding > X11 graphics take up a lot of bandwidth. If your remote host is some distance away (i.e. not on the LAN), then you'll probably suffer sluggishness in your exported X11 applications. > Instead of interacting with the GUI using X11 forwarding, consider something else that has better optimization/compression, such as VNC or NX/FreeNX. > Actually well written X11 programs don't comsume a lot of bandwidth. The main issue with X11 is the abysmal badly written Xlib which performs a full synchronous roundtrip for almost every operation, while many operations could be performed asynchronously. If using another X11 protocol backend, like Xcb and not doing moronic things like rasterizing the whole GUI on the client and then just blitting the damn thing over the network, plain X11 over TCP over a low bandwidth, high latency connection is actually very usable. However many programs are written badly. https://superuser.com/questions/1217280/why-is-x11-forwarding-so-inefficient > X11, by default, doesn't do any compression on the network data that gets passed between the application and the display server. As you mentioned, you can use the -C option on SSH to enable compression, and while this does help, it's not optimized for compressing graphical data. Compared to formats like H.264 which can obtain compression rates of 100 to 1, the -C compression will be lucky to achieve 2 to 1 compression. A better solution is to use a graphics or video optimized codec for the X11 video, but we have to be careful not to make it too lossy as desktops generally need to have sharper images than a movie so the user can still clearly read the text and make out fine details. https://unix.stackexchange.com/questions/286691/more-efficient-x-forwarding https://superuser.com/questions/1400952/x11-forwarding-and-efficiency > 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. To 3: Partial present seems to work with Basic. Was it broken in February 2019 or just not enough in regard to scroll performance? Anyway, if users choose X11 forwarding, they consciously or unconsciously prefer a technically bad solution over more performant and more secure ones (regular remote desktop solutions).