X11 - Forwarding and efficiency

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












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?










share|improve this question



















  • 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.

    – sampablokuper
    Feb 1 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
    Feb 2 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
    Feb 2 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
    Feb 2 at 7:53















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?










share|improve this question



















  • 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.

    – sampablokuper
    Feb 1 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
    Feb 2 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
    Feb 2 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
    Feb 2 at 7:53













12












12








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?










share|improve this question
















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?







xorg remote-access x11-forwarding






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 1 at 18:27









Marc.2377

5991032




5991032










asked Feb 1 at 11:04









FangFang

190111




190111







  • 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.

    – sampablokuper
    Feb 1 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
    Feb 2 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
    Feb 2 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
    Feb 2 at 7:53












  • 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.

    – sampablokuper
    Feb 1 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
    Feb 2 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
    Feb 2 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
    Feb 2 at 7:53







2




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.

– sampablokuper
Feb 1 at 15:03





"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.

– sampablokuper
Feb 1 at 15:03




1




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
Feb 2 at 3:54






"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
Feb 2 at 3:54





1




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
Feb 2 at 7:01






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
Feb 2 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
Feb 2 at 7:53





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
Feb 2 at 7:53










1 Answer
1






active

oldest

votes


















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.







share|improve this answer




















  • 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.

    – Toby Speight
    Feb 1 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
    Feb 2 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"?

    – grawity
    Feb 2 at 16:15










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "3"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1400952%2fx11-forwarding-and-efficiency%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









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.







share|improve this answer




















  • 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.

    – Toby Speight
    Feb 1 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
    Feb 2 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"?

    – grawity
    Feb 2 at 16:15















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.







share|improve this answer




















  • 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.

    – Toby Speight
    Feb 1 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
    Feb 2 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"?

    – grawity
    Feb 2 at 16:15













30












30








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.







share|improve this answer
















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.








share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 1 at 11:34

























answered Feb 1 at 11:21









grawitygrawity

239k37506561




239k37506561







  • 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.

    – Toby Speight
    Feb 1 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
    Feb 2 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"?

    – grawity
    Feb 2 at 16:15












  • 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.

    – Toby Speight
    Feb 1 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
    Feb 2 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"?

    – grawity
    Feb 2 at 16:15







1




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.

– Toby Speight
Feb 1 at 14:33





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.

– Toby Speight
Feb 1 at 14:33




1




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
Feb 2 at 15:30





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
Feb 2 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"?

– grawity
Feb 2 at 16:15





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"?

– grawity
Feb 2 at 16:15

















draft saved

draft discarded
















































Thanks for contributing an answer to Super User!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1400952%2fx11-forwarding-and-efficiency%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?