5 ms·

"We've built X. It allows you to run graphical applications over a network." "Here's an optimization for when the X display is the same machine as the process.

by billpg 2y ago

"We've built X. It allows you to run graphical applications over a network." "Here's an optimization for when the X display is the same machine as the process." "We've built Wayland. We all run applications on the same machine as the display and X gets in the way." "We'd like to run applications from machines over the internet." "We've built Wprs. It allows you to run graphical applications over a network." That's the circle of life.....

kaba0 2y ago
X being network transparent hasn’t been true for decades — no one uses xmotif and similar GUI libs, they just grab a buffer and paint stuff themselves, making the X protocol an inefficient format to carry bitmaps around. Local-first is the correct approach as the end computers are significantly more powerful than 30 years ago. Plus, we can transport bitmaps far more efficiently with compression, so it’s quite obviously an improvement on every metric, it is pretty shortsighted to note it down as circular development.
- aragilar 2y ago
  I'm not sure this is true for apps that commonly forwarded though? My impression is tk for example uses xlib heavily and so has much better behaviour over the network than GTK, and the majority of apps I've seen where the audience uses X forwarding commonly seem to be using tk.
  - epcoa 2y ago
    Somebody in a thread the other day lamented how almost always X clients are sensitive to network drops. And the suggestion is to use Xpra! (It’s “like tmux”) Xpra doesn’t forward X though, it is a rootless X server that then forwards everything as compressed bitmaps like VNC. It’s a nice homage to how awful X is even at its one oft purported benefit around here. X11 network transparency is a pretty poor technology, one can go through each of the “Fallacies of Distributed Computing” document to understand why.
    - 1oooqooq 2y ago
      and instead of x12 modernizing the network and access layer, breaking backwards compatibility with x11, they dropped those two features, and rewrote everything else which worked, and broke backwards compatibility. it's hard to defend.
      - kaba0 2y ago
        I’m fairly sure the very maintainers of X11 knew more about the topic than you. And you get backwards compatibility with stuff like xwayland.
- StillBored 2y ago
  "no one uses xmotif and similar GUI libs, they just grab a buffer and paint stuff themselves, making the X protocol an inefficient format to carry bitmaps around." While true for things like firefox, and GUI libs that think they know better than the host, its not ideal, and entirely dependent on the language/toolkit being used. And it's a side effect of X being too low level and not having a standard widget toolkit as one gets on Windows/mac. On those platforms, it's not just the widgets but file open dialogs provided by the OS, skinned consistently across applications, and things like global keyboard shortcuts (ex, copy/paste) tend to work close to 100% of the time. If one goes back to the win3.x/macos7/etc timeframe it was almost unheard of for applications not to follow system wide color themes. WHich is why "dark mode" 1995 worked more reliably than it does on any platforms today. Today, doing something like inverting to a "dark" theme is suddenly something that each application hacks in, and when the OS provides a theme option, the applications frequently don't follow it correctly/etc.
  - cowboylowrez 2y ago
    I'm glad I found this thread, firefox really jumped the shark with remote x at some point, it always confused me why this happened all of a sudden. All I could find out from googling was the wayland thing and all of a sudden how x over the network wasn't cool anymore lol
znpy 2y ago
It’s not a circle, it’s plain stupidity. Running stuff over the network has always been a requirement and somehow wayland people decided so ignore that requirement, producing an half-assed spec and quarter-assed implementations. All this could have been avoided, and yet here we are…
- Zambyte 2y ago
  What a strange comment. I was running applications over the network years ago using Wayland. Just because a new tool exists that you can do it with doesn't mean it doesn't work. Running software locally has been a requirement for at least a few years by my calendar, yet I don't see you complaining about their network-first-patch-local-after approach.
  - karma_pharmer 2y ago
    How dare you call my quarter-ass strange! I demand a duel. Tablets at twenty paces. No BitBlts.
delusional 2y ago
The X protocol is from a time before proprietary/differentiated GPU devices. Network transparency looks very different when you're doing simple stuff like "render a line" or "render a box". Nowadays even 2D applications are essentially sending arbitrary programs to a standalone accelerator (the GPU) which they expect to have incredible bandwidth. In the simple case of the past, it made sense to send the primitives. In the complex now it's way more robust to stuff the bitmap over the wire.
- StillBored 2y ago
  No, way, that can't be right....? Much of the reason RDP and WebGL work so well is that they send the raw command stream/assets to the rendering side rather than continuously sending a stream of compressed frame buffer data. RDP, for example, can send the raw video stream being played, or recompress it, and send it rather than trying to render it to the screen and then recompress the resulting output, which is what you get with something like VNC. Thats why its completly possible to stream video over RDP on links that choke up pretty much everything else. For an incredibly wide range of things, high level GUI command streams are going to be significantly less data intensive than the resulting rendered and compressed video stream. AKA the GUI command stream is itself an applicaiton specific compresion algorithm. A draw line command can affect tens of thousands of pixels around the line due to antialiasing, and that won't ever compress as well as the drawing (x,y,brush). So while sending a bunch of textures, shaders, and the like might be a huge initial overhead, its going to quickly pay for itself over the lifetime as used in something like a game/etc, particularly at high resolution and refresh rates. Never mind, of course, the overhead of doing a bunch of local rendering, compressing it, sending it over the wire, and doing video playback. If it weren't for hardware video encoding/decoding, it would essentially be a case of pegged CPUs on both sides just doing graphical updates. This may just be one of the issues with Wayland compositing; over time, I've become more convinced that the loss of standard GUI widgets and a serializable drawing stream might be a huge mistake.
  - akvadrako 2y ago
    RDP hadn't worked that way for years. https://techcommunity.microsoft.com/t5/security-compliance-and-identity/remotefx-adaptive-graphics-in-windows-server-2012-and-windows-8/ba-p/247454 https://techcommunity.microsoft.com/t5/security-compliance-a... And we do have hardware encoding / decoding. The latency is quite reasonable, like 15ms in total, so modern solutions like parsec work for any app, including games and CAD.
epcoa 2y ago
There are two seemingly irreconcilable camps at this point as to whether X itself is fundamentally sound technology for remote display or any kind of display technology going into the future. There are many reasons hashed out to death about this. Yes you could continue to add new X extensions, and the second system effect is a real consideration, but neither of those are absolute arguments against starting fresh without legacy baggage both in design and implementation. X earned its place in the UHH over 30 years ago, at least let’s not pretend this was some universally beloved technology either.
- IshKebab 2y ago
  > There are two seemingly irreconcilable camps at this point as to whether X itself is fundamentally sound technology for remote display or any kind of display technology going into the future. Are there? I don't think anyone seriously thinks X is the way forward do they? They just don't like some of Wayland's poor choices, which I think is fair.
  - immibis 2y ago
    As someone who actually researched X I don't really see the problems with it. Xorg has some, but the X11 protocol seems to have fewer problems than the Wayland protocol. For instance it already supports mixing windows with different colour modes, which can be used for HDR.
    - epcoa 2y ago
      X11 the base protocol is wholly unsuited to the needs of modern display systems, full stop. Moreover, the base security profile is also completely outdated. Now you can always extend the protocol, and continue to use the myriad extensions over the years like XRENDER, DBE, DnD, etc, etc (or paper over deficiencies with contraptions like NX/x2go and Xpra). The question is what useful benefit is being provided by that miniscule still relevant base that justifies its existence along with the other legacy cruft and baggage. "X11 seems to have fewer problems than the Wayland protocol" is too vague to be cogent so I will not address it. But the argument is more than just X11 vs Wayland, as Wayland isn't the only alternative display system nor is it the only answer to network transparent remote display technology either. "Wayland sucks" really is not a valid response to "X I don't really see the problems with it." True, X11 the wire protocol isn't the most horrible thing in a world where SOAP exists, but in practice the latency story is overall bad. Yes you can pipeline with xcb and not with Xlib, so a few of the rehashed latency issues by the peanut gallery are false attribution, but the core protocol still makes many basic operations inherently synchronous and strictly ordered, many just a consequence of how the X server manages state. There are fundamental architectural issues.

by billpg 2y ago

kaba0 2y ago

X being network transparent hasn’t been true for decades — no one uses xmotif and similar GUI libs, they just grab a buffer and paint stuff themselves, making the X protocol an inefficient format to carry bitmaps around. Local-first is the correct approach as the end computers are significantly more powerful than 30 years ago. Plus, we can transport bitmaps far more efficiently with compression, so it’s quite obviously an improvement on every metric, it is pretty shortsighted to note it down as circular development.

aragilar 2y ago
I'm not sure this is true for apps that commonly forwarded though? My impression is tk for example uses xlib heavily and so has much better behaviour over the network than GTK, and the majority of apps I've seen where the audience uses X forwarding commonly seem to be using tk.
- epcoa 2y ago
  Somebody in a thread the other day lamented how almost always X clients are sensitive to network drops. And the suggestion is to use Xpra! (It’s “like tmux”) Xpra doesn’t forward X though, it is a rootless X server that then forwards everything as compressed bitmaps like VNC. It’s a nice homage to how awful X is even at its one oft purported benefit around here. X11 network transparency is a pretty poor technology, one can go through each of the “Fallacies of Distributed Computing” document to understand why.
  - 1oooqooq 2y ago
    and instead of x12 modernizing the network and access layer, breaking backwards compatibility with x11, they dropped those two features, and rewrote everything else which worked, and broke backwards compatibility. it's hard to defend.
    - kaba0 2y ago
      I’m fairly sure the very maintainers of X11 knew more about the topic than you. And you get backwards compatibility with stuff like xwayland.
StillBored 2y ago
"no one uses xmotif and similar GUI libs, they just grab a buffer and paint stuff themselves, making the X protocol an inefficient format to carry bitmaps around." While true for things like firefox, and GUI libs that think they know better than the host, its not ideal, and entirely dependent on the language/toolkit being used. And it's a side effect of X being too low level and not having a standard widget toolkit as one gets on Windows/mac. On those platforms, it's not just the widgets but file open dialogs provided by the OS, skinned consistently across applications, and things like global keyboard shortcuts (ex, copy/paste) tend to work close to 100% of the time. If one goes back to the win3.x/macos7/etc timeframe it was almost unheard of for applications not to follow system wide color themes. WHich is why "dark mode" 1995 worked more reliably than it does on any platforms today. Today, doing something like inverting to a "dark" theme is suddenly something that each application hacks in, and when the OS provides a theme option, the applications frequently don't follow it correctly/etc.
- cowboylowrez 2y ago
  I'm glad I found this thread, firefox really jumped the shark with remote x at some point, it always confused me why this happened all of a sudden. All I could find out from googling was the wayland thing and all of a sudden how x over the network wasn't cool anymore lol

znpy 2y ago

It’s not a circle, it’s plain stupidity. Running stuff over the network has always been a requirement and somehow wayland people decided so ignore that requirement, producing an half-assed spec and quarter-assed implementations. All this could have been avoided, and yet here we are…

Zambyte 2y ago
What a strange comment. I was running applications over the network years ago using Wayland. Just because a new tool exists that you can do it with doesn't mean it doesn't work. Running software locally has been a requirement for at least a few years by my calendar, yet I don't see you complaining about their network-first-patch-local-after approach.
- karma_pharmer 2y ago
  How dare you call my quarter-ass strange! I demand a duel. Tablets at twenty paces. No BitBlts.

delusional 2y ago

The X protocol is from a time before proprietary/differentiated GPU devices. Network transparency looks very different when you're doing simple stuff like "render a line" or "render a box". Nowadays even 2D applications are essentially sending arbitrary programs to a standalone accelerator (the GPU) which they expect to have incredible bandwidth. In the simple case of the past, it made sense to send the primitives. In the complex now it's way more robust to stuff the bitmap over the wire.

StillBored 2y ago
No, way, that can't be right....? Much of the reason RDP and WebGL work so well is that they send the raw command stream/assets to the rendering side rather than continuously sending a stream of compressed frame buffer data. RDP, for example, can send the raw video stream being played, or recompress it, and send it rather than trying to render it to the screen and then recompress the resulting output, which is what you get with something like VNC. Thats why its completly possible to stream video over RDP on links that choke up pretty much everything else. For an incredibly wide range of things, high level GUI command streams are going to be significantly less data intensive than the resulting rendered and compressed video stream. AKA the GUI command stream is itself an applicaiton specific compresion algorithm. A draw line command can affect tens of thousands of pixels around the line due to antialiasing, and that won't ever compress as well as the drawing (x,y,brush). So while sending a bunch of textures, shaders, and the like might be a huge initial overhead, its going to quickly pay for itself over the lifetime as used in something like a game/etc, particularly at high resolution and refresh rates. Never mind, of course, the overhead of doing a bunch of local rendering, compressing it, sending it over the wire, and doing video playback. If it weren't for hardware video encoding/decoding, it would essentially be a case of pegged CPUs on both sides just doing graphical updates. This may just be one of the issues with Wayland compositing; over time, I've become more convinced that the loss of standard GUI widgets and a serializable drawing stream might be a huge mistake.
- akvadrako 2y ago
  RDP hadn't worked that way for years. https://techcommunity.microsoft.com/t5/security-compliance-and-identity/remotefx-adaptive-graphics-in-windows-server-2012-and-windows-8/ba-p/247454 https://techcommunity.microsoft.com/t5/security-compliance-a... And we do have hardware encoding / decoding. The latency is quite reasonable, like 15ms in total, so modern solutions like parsec work for any app, including games and CAD.

epcoa 2y ago

There are two seemingly irreconcilable camps at this point as to whether X itself is fundamentally sound technology for remote display or any kind of display technology going into the future. There are many reasons hashed out to death about this. Yes you could continue to add new X extensions, and the second system effect is a real consideration, but neither of those are absolute arguments against starting fresh without legacy baggage both in design and implementation. X earned its place in the UHH over 30 years ago, at least let’s not pretend this was some universally beloved technology either.

IshKebab 2y ago
> There are two seemingly irreconcilable camps at this point as to whether X itself is fundamentally sound technology for remote display or any kind of display technology going into the future. Are there? I don't think anyone seriously thinks X is the way forward do they? They just don't like some of Wayland's poor choices, which I think is fair.
- immibis 2y ago
  As someone who actually researched X I don't really see the problems with it. Xorg has some, but the X11 protocol seems to have fewer problems than the Wayland protocol. For instance it already supports mixing windows with different colour modes, which can be used for HDR.
  - epcoa 2y ago
    X11 the base protocol is wholly unsuited to the needs of modern display systems, full stop. Moreover, the base security profile is also completely outdated. Now you can always extend the protocol, and continue to use the myriad extensions over the years like XRENDER, DBE, DnD, etc, etc (or paper over deficiencies with contraptions like NX/x2go and Xpra). The question is what useful benefit is being provided by that miniscule still relevant base that justifies its existence along with the other legacy cruft and baggage. "X11 seems to have fewer problems than the Wayland protocol" is too vague to be cogent so I will not address it. But the argument is more than just X11 vs Wayland, as Wayland isn't the only alternative display system nor is it the only answer to network transparent remote display technology either. "Wayland sucks" really is not a valid response to "X I don't really see the problems with it." True, X11 the wire protocol isn't the most horrible thing in a world where SOAP exists, but in practice the latency story is overall bad. Yes you can pipeline with xcb and not with Xlib, so a few of the rehashed latency issues by the peanut gallery are false attribution, but the core protocol still makes many basic operations inherently synchronous and strictly ordered, many just a consequence of how the X server manages state. There are fundamental architectural issues.