5 ms·

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 lan

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

by Seirdy 5y ago

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.