14 ms·

1. Wayland does support remote execution; see waypipe for an example. 2. X11 does lack critical features that lots of users need: GUI isolation (a very basic s

by Seirdy 5y ago

1. Wayland does support remote execution; see waypipe for an example. 2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).

vidarh 5y ago
X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.
- Seirdy 5y ago
  ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
  - qwerty456127 5y ago
    What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
    - vidarh 5y ago
      Screen tearing is largely a software issue anyway - the moment you have hardware capable of double buffering there's no excuse for it unless you don't have sufficient memory.
    - Seirdy 5y ago
      If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason. The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.
      - qwerty456127 5y ago
        > If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason. I see. Curious that I have never noticed anything like this though. I have always been disabling compositors as I realized I don't really care if my panel is transparent. Perhaps the problem just doesn't affect Intel graphics (Raspberry Pi browsing is slow anyway so fast scrolling just doesn't exist there). UPDATE: I've just realized I've actually seen screen tearing many times - always within specific Windows apps ran with Wine, e.g. Total Commander.
    - kaba0 5y ago
      Have you tried playing a video? Or moving a window around fast? Without a compositor there will be tearing on X. With a compositor, X is just a useless middleman.
      - vidarh 5y ago
        There's nothing stopping an X server implementation from doing compositing natively.
        kaba0 5y ago
        Other than writing an X server implementation is akin to writing a web browser from scratch?
        vidarh 5y ago
        There's absolutely no reason to write an X server from scratch to add native compositing support. You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support older clients, and make the main server itself only support the subset of the X protocol modern clients speak.
        qwerty456127 5y ago
        > You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. If so, why are we observing apparent shortage of developers to maintain the actual Xorg? I can't believe there are no people interested in maintaining it in the whole world. I thought it's so complex it just requires much more expertise and dedication than anybody is ready to invest.
        vidarh 5y ago
  - vidarh 5y ago
    The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's. You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.
    - Seirdy 5y ago
      I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL
      - qwerty456127 5y ago
        > ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio? > I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. > The difference will widen as Vulkan I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that
        Seirdy 5y ago
        > Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more. I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link. A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.
- DonHopkins 5y ago
  Mid 80s hardware, actually. Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here: https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami. https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions: WHAT IS YOUR DISPLAY? display = XOpenDisplay("unix:0"); WHAT IS YOUR ROOT? root = RootWindow(display, DefaultScreen(display)); AND WHAT IS YOUR WINDOW? win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel( display, DefaultScreen(display)), WhitePixel( display, DefaultScreen(display))); OH ALL RIGHT, YOU CAN GO ON. (the next client tries to connect to the server) WHAT IS YOUR DISPLAY? display = XOpenDisplay("unix:0"); WHAT IS YOUR COLORMAP? cmap = DefaultColormap(display, DefaultScreen(display)); AND WHAT IS YOUR FAVORITE COLOR? favorite_color = 0; /* Black. */ /* Whoops! No, I mean: */ favorite_color = BlackPixel(display, DefaultScreen(display)); /* AAAYYYYEEEEE!! */ (client dumps core & falls into the chasm) WHAT IS YOUR DISPLAY? display = XOpenDisplay("unix:0"); WHAT IS YOUR VISUAL? struct XVisualInfo vinfo; if (XMatchVisualInfo(display, DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual; AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST? /* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */ WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!! (server dumps core & falls into the chasm)
  - vidarh 5y ago
    > Mid 80s hardware, actually. I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :) > WHAT IS YOUR ROOT? A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though. The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value. So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better. There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach. In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients. EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.
erik_seaberg 5y ago
Waypipe ships client-rendered images across the network; datacenters would fall back to software rendering because there’s no way to take advantage of a user’s desktop GPU. I think the industry will continue moving to Javascript or Wasm apps as the most widely portable and accelerated remote display system we have.
- andrewshadura 5y ago
  > Waypipe ships client-rendered images across the network That's also exactly what most modern GUI toolkits do when they run on X11.
  - WalterGR 5y ago
    Sorry if I'm being obtuse, but... why would X11 toolkits need to ship client-rendered images across the network? Doesn't the server tell the client what to render, and the rendering happens on the client? Why would that result then be shipped over the network? https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System
    - andrewshadura 5y ago
      That’s been tried, but most toolkits stopped doing that because it was unreliable, slow, and the number of primitives offered by X wasn’t sufficient for any modern GUI.
    - andrewshadura 5y ago
      Also, in X terminology, the server owns/controls the display, the client is the app that wants to draw a window on the server’s display. The classic architecture would be client telling server what to draw, but these days what really happens is that clients draw locally into a buffer and then tell X server to draw the contents of the buffer.

by Seirdy 5y ago

vidarh 5y ago

X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.

Seirdy 5y ago
ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
- qwerty456127 5y ago
  What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
  - vidarh 5y ago
    Screen tearing is largely a software issue anyway - the moment you have hardware capable of double buffering there's no excuse for it unless you don't have sufficient memory.
  - Seirdy 5y ago
    If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason. The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.
    - qwerty456127 5y ago
      > If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason. I see. Curious that I have never noticed anything like this though. I have always been disabling compositors as I realized I don't really care if my panel is transparent. Perhaps the problem just doesn't affect Intel graphics (Raspberry Pi browsing is slow anyway so fast scrolling just doesn't exist there). UPDATE: I've just realized I've actually seen screen tearing many times - always within specific Windows apps ran with Wine, e.g. Total Commander.
  - kaba0 5y ago
    Have you tried playing a video? Or moving a window around fast? Without a compositor there will be tearing on X. With a compositor, X is just a useless middleman.
    - vidarh 5y ago
      There's nothing stopping an X server implementation from doing compositing natively.
      - kaba0 5y ago
        Other than writing an X server implementation is akin to writing a web browser from scratch?
        vidarh 5y ago
        There's absolutely no reason to write an X server from scratch to add native compositing support. You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support older clients, and make the main server itself only support the subset of the X protocol modern clients speak.
        qwerty456127 5y ago
        > You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. If so, why are we observing apparent shortage of developers to maintain the actual Xorg? I can't believe there are no people interested in maintaining it in the whole world. I thought it's so complex it just requires much more expertise and dedication than anybody is ready to invest.
        vidarh 5y ago
- vidarh 5y ago
  The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's. You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.
  - Seirdy 5y ago
    I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL
    - qwerty456127 5y ago
      > ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio? > I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. > The difference will widen as Vulkan I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that
      - Seirdy 5y ago
        > Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more. I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link. A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.
DonHopkins 5y ago
Mid 80s hardware, actually. Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here: https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami. https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions: WHAT IS YOUR DISPLAY? display = XOpenDisplay("unix:0"); WHAT IS YOUR ROOT? root = RootWindow(display, DefaultScreen(display)); AND WHAT IS YOUR WINDOW? win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel( display, DefaultScreen(display)), WhitePixel( display, DefaultScreen(display))); OH ALL RIGHT, YOU CAN GO ON. (the next client tries to connect to the server) WHAT IS YOUR DISPLAY? display = XOpenDisplay("unix:0"); WHAT IS YOUR COLORMAP? cmap = DefaultColormap(display, DefaultScreen(display)); AND WHAT IS YOUR FAVORITE COLOR? favorite_color = 0; /* Black. */ /* Whoops! No, I mean: */ favorite_color = BlackPixel(display, DefaultScreen(display)); /* AAAYYYYEEEEE!! */ (client dumps core & falls into the chasm) WHAT IS YOUR DISPLAY? display = XOpenDisplay("unix:0"); WHAT IS YOUR VISUAL? struct XVisualInfo vinfo; if (XMatchVisualInfo(display, DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual; AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST? /* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */ WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!! (server dumps core & falls into the chasm)
- vidarh 5y ago
  > Mid 80s hardware, actually. I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :) > WHAT IS YOUR ROOT? A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though. The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value. So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better. There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach. In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients. EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.

erik_seaberg 5y ago

Waypipe ships client-rendered images across the network; datacenters would fall back to software rendering because there’s no way to take advantage of a user’s desktop GPU. I think the industry will continue moving to Javascript or Wasm apps as the most widely portable and accelerated remote display system we have.

andrewshadura 5y ago
> Waypipe ships client-rendered images across the network That's also exactly what most modern GUI toolkits do when they run on X11.
- WalterGR 5y ago
  Sorry if I'm being obtuse, but... why would X11 toolkits need to ship client-rendered images across the network? Doesn't the server tell the client what to render, and the rendering happens on the client? Why would that result then be shipped over the network? https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System
  - andrewshadura 5y ago
    That’s been tried, but most toolkits stopped doing that because it was unreliable, slow, and the number of primitives offered by X wasn’t sufficient for any modern GUI.
  - andrewshadura 5y ago
    Also, in X terminology, the server owns/controls the display, the client is the app that wants to draw a window on the server’s display. The classic architecture would be client telling server what to draw, but these days what really happens is that clients draw locally into a buffer and then tell X server to draw the contents of the buffer.