17 ms·

Waypipe https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/

md8z 5y ago
Waypipe isn't relevant in this case, this post is about remotely invoking an RPC call over D-Bus. It's actually pretty trivial to forward a D-Bus socket using ssh -L.
- deleted 5y ago
  [deleted]
gspr 5y ago
It's lovely. Some elaboration: Waypipe takes a completely different approach from X forwarding. X forwarding entails shipping a bunch of X drawing commands across the network. This is incredibly inefficient for modern use-cases, where local rendering would be done through direct rendering instead (more details here: https://superuser.com/a/1217295/58251 https://superuser.com/a/1217295/58251). Waypipe takes a step back and instead just renders a low-latency H264 video stream that it ships across the network. It won't be pixel-perfect, but a lot snappier! (In principle there's no obstacle to doing it pixel-perfect either, at the expense of bandwidth)
- AshamedCaptain 5y ago
  Wtf? Sending drawing commands over the wire is WAY more efficient for the vast majority of cases than sending compressed H264 video, and DEFINITELY much lower latency no matter what the codec latency is! It was even mentioned as a con of Wayland in the recent story "What is wrong with desktop Linux" right here on HN.
  - dyingkneepad 5y ago
    The problem with X11 drawing commands is that there are a lot of round-trips over the network. Client asks for something, has to wait for the server response before proceeding, then it asks something else, etc. XCB tries to help mitigate problems that Xlib created that were not in the X11 protocol, but it's still highly inefficient. In practice, running everything locally and then just streaming the framebuffer ends up being faster. Not that we couldn't come up with a fast-over-the-network protocol. It's just that it's not really here.
    - nybble41 5y ago
      > Not that we couldn't come up with a fast-over-the-network protocol. It's just that it's not really here. In practice the "fast-over-the-network" protocol ends up being HTTPS + HTML + CSS + JavaScript, with a web browser as the client.
      - em-bee 5y ago
        i don't know why parent was being downvoted. this is exactly why i am building web applications instead of desktop apps if i expect to run the application on a remote machine. a very good example is the deluge torrent client. by concept it is a desktop gui application. but it is designed in a client-server mode that allows the actual gui to run anywhere and access a backend through a thin protocol that provides a much better experience than remote X would. it has both a traditional gui interface and a well designed webinterface. there is no reason we could not be designing more applications like this.
    - sprash 5y ago
      > The problem with X11 drawing commands is that there are a lot of round-trips over the network. This is not a problem with drawing commands or the fact that the X11 wire protocol supposedly inefficient (it is actually very efficient). It is a problem of GTK and Qt that introduce unnecessary round trips. Both tooklits (which are mainly the reason the Linux never took off because they are pure garbage) never cared in the least about remote applications. As comparison libXt based toolkits like motif run perfectly fine over the network and are very responsive.
      - md8z 5y ago
        I'd advise against using hyperbole and dismissing projects as "pure garbage". I tried to ask you this before but I would be really interested to know what your use case for motif is in 2021. That seems like a recipe for pain and frustration, significantly moreso than any pain and frustration you would have had with GTK and Qt.
        5y ago
  - md8z 5y ago
    That article wasn't really accurate, most clients aren't using the X drawing commands anymore. The "vast majority of cases" has moved to using GL or Vulkan, which also doesn't serialize over the network.
    - cesarb 5y ago
      > The "vast majority of cases" has moved to using GL or Vulkan, which also doesn't serialize over the network. IIRC, GLX did serialize over the network (though AFAIK limited to an older version of OpenGL; the vast majority of cases has moved to a newer version of OpenGL).
      - md8z 5y ago
        Yeah, indirect GLX is limited to OpenGL 1.4 and earlier. It also isn't even enabled by default on recent Xorg releases, you have to opt-into it.
    - sprash 5y ago
      Then why not use a wire protocol for Vulkan? SPIRV already exists. It only needs some wrapper code tacked on to work as a X extension and you have perfectly efficient server side rendering that potentially works even over the network without breaking anybodies backwards compatibility.
      - md8z 5y ago
        I'm very confused by this comment, SPIR-V is not a wire protocol for Vulkan. And you can't really serialize Vulkan over the network, that breaks things like vkMapMemory. If you want something like a remote Vulkan, the thing to watch there would be WebGPU.
        sprash 5y ago
        WebGPU translates 1:1 to SPIR-V.
        5y ago
  - acdha 5y ago
    > Sending drawing commands over the wire is WAY more efficient for the vast majority of cases than sending compressed H264 video, and DEFINITELY much lower latency no matter what the codec latency is! How closely have you profiled this? Back in the early 2000s I found there was a fairly strong divide between the applications which used X in the traditional manner, where sending the command across the wire could potentially be faster modulo loss of parallelism, and the growing number of applications which were doing more of the graphics internally so they could control font rendering, antialiasing, blending, etc. directly and were just slinging bitmaps back and forth. I'd expect that would have gotten worse over time rather than better.
    - pxc 5y ago
      > > Sending drawing commands over the wire is WAY more efficient for the vast majority of cases than sending compressed H264 video, and DEFINITELY much lower latency no matter what the codec latency is! > > How closely have you profiled this? Yes. Anyone who actually experimented with tools like X2Go or Xpra/winswitch vs. plain old `ssh -Y -C`, even back in the mid aughts already, would know that GP is wrong.
      - AshamedCaptain 5y ago
        I am not sure which GP you are referring too, since I am a heavy user of the original NoMachine, and it has incredibly better latency even when used over long-latency links (or should I say: specially when used over long-latency links). The new commercial NoMachine also uses H264 and I outright refuse to upgrade to it since it's just worse -- though it makes commercial sense for them since they want to support Windows. But also just ask anyone who has used RDP versus something like VNC.
        pxc 5y ago
        I was indeed referring to you! I'm surprised by your account, and glad that you've given it. This is mine: In high school, I was a Linux hobbyist and I also had a habit of forgetting and losing documents I needed for school. Additionally, the school's computers not completely locked down, but the selection of software on them was very limited. So I played with a lot of remote access solutions for accessing my home desktop, both to do things on it that I couldn't do at school (like browse an uncensored web or using an IDE I couldn't install on the school computers) and to access my files or even running applications. I tested a lot of stuff, both with Windows clients and with Linux clients (but I was limited to the former at school). I tried X2Go, TigerVNC, plain Xpra, SSH (with normal and insecure forwarding, with and without compression), NX (FreeNX on the server, but with the proprietary client alongside several open-source clients), and WinSwitch, which was some nice tooling built around Xpra. (On the LAN, I even messed around with VirtualGL for 3D acceleration with remote applications.) Xpra was the preferred choice, and WinSwitch using Xpra and H.264 encoding worked best for me when I was away from home. Using plain X forwarding, I noticed that some applications were painfully laggy, especially Eclipse and Firefox. But even with my modest home internet connection (with especially low bandwidth on the uplink), the H.264-based solutions were very usable for any application I threw at them. > But also just ask anyone who has used RDP versus something like VNC. For connecting to full desktop sessions, I remember tigervnc being way faster than x11rdp.
  - copperx 5y ago
    I agree. And that's why Microsoft's RDP is still going.
  - kaba0 5y ago
    What about drawing this small bitmap here? Oh wait it’s now animating? Just calculate the amount of those in your average interface and say which is faster, compressing/decompressing on both side, or uncompresses draw commands that will have to transmit the whole thing serially?
- mikepurvis 5y ago
  I imagine that historically, sending draw commands would have been highly efficient and quite responsive— show these form controls, this text field with these contents, etc. But as common use-cases have gotten more and more graphical, it's made more sense to just render a buffer and send that instead.
  - jhgb 5y ago
    I was under the impression that pretty much anything recent used client-side rendering anyway? For example, anything Qt based.
    - jcelerier 5y ago
      Nope, Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to ; I use it that way and it's pretty cool, last week I was debugging an app running on a raspberry pi behind a university proxy a few hundred kilometers away from home and it worked fine, and has the very nice benefit of using my .Xresources (e.g. for my local screen's hi DPI)
      - jhgb 5y ago
        > Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? In any case, if it can use server-side X11 painting, that doesn't mean that it doesn't support the opposite, which is what I meant -- unless the Qt devs completely removed the code for client-side rendering, it's basically already ready for that scenario (passing pixmaps), isn't it? > and has the very nice benefit of using my .Xresources (e.g. for my local screen's hi DPI) Not quite sure how that is relevant. Isn't it possible to query that from the client, then produce a pixmap in an appropriate resolution? That should be transparent.
        jcelerier 5y ago
        > It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? I was talking about the flag. Qt by itself can render however you want it to, if someone wanted to make a platform abstraction that would render Qt apps with ncurses that would be possible too. > it's basically already ready for that scenario (passing pixmaps), isn't it? sure, if you use it as a local X11 client (or on other platforms than X11) it's what happens too

md8z 5y ago

Waypipe isn't relevant in this case, this post is about remotely invoking an RPC call over D-Bus. It's actually pretty trivial to forward a D-Bus socket using ssh -L.

deleted 5y ago
[deleted]

gspr 5y ago

It's lovely. Some elaboration: Waypipe takes a completely different approach from X forwarding. X forwarding entails shipping a bunch of X drawing commands across the network. This is incredibly inefficient for modern use-cases, where local rendering would be done through direct rendering instead (more details here: https://superuser.com/a/1217295/58251 https://superuser.com/a/1217295/58251). Waypipe takes a step back and instead just renders a low-latency H264 video stream that it ships across the network. It won't be pixel-perfect, but a lot snappier! (In principle there's no obstacle to doing it pixel-perfect either, at the expense of bandwidth)

AshamedCaptain 5y ago
Wtf? Sending drawing commands over the wire is WAY more efficient for the vast majority of cases than sending compressed H264 video, and DEFINITELY much lower latency no matter what the codec latency is! It was even mentioned as a con of Wayland in the recent story "What is wrong with desktop Linux" right here on HN.
- dyingkneepad 5y ago
  The problem with X11 drawing commands is that there are a lot of round-trips over the network. Client asks for something, has to wait for the server response before proceeding, then it asks something else, etc. XCB tries to help mitigate problems that Xlib created that were not in the X11 protocol, but it's still highly inefficient. In practice, running everything locally and then just streaming the framebuffer ends up being faster. Not that we couldn't come up with a fast-over-the-network protocol. It's just that it's not really here.
  - nybble41 5y ago
    > Not that we couldn't come up with a fast-over-the-network protocol. It's just that it's not really here. In practice the "fast-over-the-network" protocol ends up being HTTPS + HTML + CSS + JavaScript, with a web browser as the client.
    - em-bee 5y ago
      i don't know why parent was being downvoted. this is exactly why i am building web applications instead of desktop apps if i expect to run the application on a remote machine. a very good example is the deluge torrent client. by concept it is a desktop gui application. but it is designed in a client-server mode that allows the actual gui to run anywhere and access a backend through a thin protocol that provides a much better experience than remote X would. it has both a traditional gui interface and a well designed webinterface. there is no reason we could not be designing more applications like this.
  - sprash 5y ago
    > The problem with X11 drawing commands is that there are a lot of round-trips over the network. This is not a problem with drawing commands or the fact that the X11 wire protocol supposedly inefficient (it is actually very efficient). It is a problem of GTK and Qt that introduce unnecessary round trips. Both tooklits (which are mainly the reason the Linux never took off because they are pure garbage) never cared in the least about remote applications. As comparison libXt based toolkits like motif run perfectly fine over the network and are very responsive.
    - md8z 5y ago
      I'd advise against using hyperbole and dismissing projects as "pure garbage". I tried to ask you this before but I would be really interested to know what your use case for motif is in 2021. That seems like a recipe for pain and frustration, significantly moreso than any pain and frustration you would have had with GTK and Qt.
      - 5y ago
- md8z 5y ago
  That article wasn't really accurate, most clients aren't using the X drawing commands anymore. The "vast majority of cases" has moved to using GL or Vulkan, which also doesn't serialize over the network.
  - cesarb 5y ago
    > The "vast majority of cases" has moved to using GL or Vulkan, which also doesn't serialize over the network. IIRC, GLX did serialize over the network (though AFAIK limited to an older version of OpenGL; the vast majority of cases has moved to a newer version of OpenGL).
    - md8z 5y ago
      Yeah, indirect GLX is limited to OpenGL 1.4 and earlier. It also isn't even enabled by default on recent Xorg releases, you have to opt-into it.
  - sprash 5y ago
    Then why not use a wire protocol for Vulkan? SPIRV already exists. It only needs some wrapper code tacked on to work as a X extension and you have perfectly efficient server side rendering that potentially works even over the network without breaking anybodies backwards compatibility.
    - md8z 5y ago
      I'm very confused by this comment, SPIR-V is not a wire protocol for Vulkan. And you can't really serialize Vulkan over the network, that breaks things like vkMapMemory. If you want something like a remote Vulkan, the thing to watch there would be WebGPU.
      - sprash 5y ago
        WebGPU translates 1:1 to SPIR-V.
        5y ago
- acdha 5y ago
  > Sending drawing commands over the wire is WAY more efficient for the vast majority of cases than sending compressed H264 video, and DEFINITELY much lower latency no matter what the codec latency is! How closely have you profiled this? Back in the early 2000s I found there was a fairly strong divide between the applications which used X in the traditional manner, where sending the command across the wire could potentially be faster modulo loss of parallelism, and the growing number of applications which were doing more of the graphics internally so they could control font rendering, antialiasing, blending, etc. directly and were just slinging bitmaps back and forth. I'd expect that would have gotten worse over time rather than better.
  - pxc 5y ago
    > > Sending drawing commands over the wire is WAY more efficient for the vast majority of cases than sending compressed H264 video, and DEFINITELY much lower latency no matter what the codec latency is! > > How closely have you profiled this? Yes. Anyone who actually experimented with tools like X2Go or Xpra/winswitch vs. plain old `ssh -Y -C`, even back in the mid aughts already, would know that GP is wrong.
    - AshamedCaptain 5y ago
      I am not sure which GP you are referring too, since I am a heavy user of the original NoMachine, and it has incredibly better latency even when used over long-latency links (or should I say: specially when used over long-latency links). The new commercial NoMachine also uses H264 and I outright refuse to upgrade to it since it's just worse -- though it makes commercial sense for them since they want to support Windows. But also just ask anyone who has used RDP versus something like VNC.
      - pxc 5y ago
        I was indeed referring to you! I'm surprised by your account, and glad that you've given it. This is mine: In high school, I was a Linux hobbyist and I also had a habit of forgetting and losing documents I needed for school. Additionally, the school's computers not completely locked down, but the selection of software on them was very limited. So I played with a lot of remote access solutions for accessing my home desktop, both to do things on it that I couldn't do at school (like browse an uncensored web or using an IDE I couldn't install on the school computers) and to access my files or even running applications. I tested a lot of stuff, both with Windows clients and with Linux clients (but I was limited to the former at school). I tried X2Go, TigerVNC, plain Xpra, SSH (with normal and insecure forwarding, with and without compression), NX (FreeNX on the server, but with the proprietary client alongside several open-source clients), and WinSwitch, which was some nice tooling built around Xpra. (On the LAN, I even messed around with VirtualGL for 3D acceleration with remote applications.) Xpra was the preferred choice, and WinSwitch using Xpra and H.264 encoding worked best for me when I was away from home. Using plain X forwarding, I noticed that some applications were painfully laggy, especially Eclipse and Firefox. But even with my modest home internet connection (with especially low bandwidth on the uplink), the H.264-based solutions were very usable for any application I threw at them. > But also just ask anyone who has used RDP versus something like VNC. For connecting to full desktop sessions, I remember tigervnc being way faster than x11rdp.
- copperx 5y ago
  I agree. And that's why Microsoft's RDP is still going.
- kaba0 5y ago
  What about drawing this small bitmap here? Oh wait it’s now animating? Just calculate the amount of those in your average interface and say which is faster, compressing/decompressing on both side, or uncompresses draw commands that will have to transmit the whole thing serially?
mikepurvis 5y ago
I imagine that historically, sending draw commands would have been highly efficient and quite responsive— show these form controls, this text field with these contents, etc. But as common use-cases have gotten more and more graphical, it's made more sense to just render a buffer and send that instead.
- jhgb 5y ago
  I was under the impression that pretty much anything recent used client-side rendering anyway? For example, anything Qt based.
  - jcelerier 5y ago
    Nope, Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to ; I use it that way and it's pretty cool, last week I was debugging an app running on a raspberry pi behind a university proxy a few hundred kilometers away from home and it worked fine, and has the very nice benefit of using my .Xresources (e.g. for my local screen's hi DPI)
    - jhgb 5y ago
      > Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? In any case, if it can use server-side X11 painting, that doesn't mean that it doesn't support the opposite, which is what I meant -- unless the Qt devs completely removed the code for client-side rendering, it's basically already ready for that scenario (passing pixmaps), isn't it? > and has the very nice benefit of using my .Xresources (e.g. for my local screen's hi DPI) Not quite sure how that is relevant. Isn't it possible to query that from the client, then produce a pixmap in an appropriate resolution? That should be transparent.
      - jcelerier 5y ago
        > It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? I was talking about the flag. Qt by itself can render however you want it to, if someone wanted to make a platform abstraction that would render Qt apps with ncurses that would be possible too. > it's basically already ready for that scenario (passing pixmaps), isn't it? sure, if you use it as a local X11 client (or on other platforms than X11) it's what happens too