3 ms·

> X originates in the 80s and it's not a design that stands the test of time. Actually the fact that X11 can be used today despite the fact that we went throug

by sprash 5y ago

> X originates in the 80s and it's not a design that stands the test of time. Actually the fact that X11 can be used today despite the fact that we went through several cycles of vastly changing GPU hardware shows that it absolutely has stood the test of time.

kaba0 5y ago
Ncurses apps can also display GUIs for a long time now, but it doesn’t mean that they are actually good solutions. The X server became a pretty useless middle man between clients and the compositor. And the vastly changed GPU hardware is the reason we should prefer a superior solution - we no longer draw as we did 3 decades ago, so we should cut out the middle man.
- sprash 5y ago
  > Ncurses apps can also display GUIs Terminal applications stood the test of time as well. For everything that is not graphical in nature they are indeed good solutions. > The X server became a pretty useless middle man between clients and the compositor. X is a middle man but far from useless. Just as Wayland is a middle man as well. And looking at the protocol actual access to GPU memory is more opaque on Wayland than on X11 and as such to me Wayland is a more intrusive middleman. If you want to "cut out the middle man" you have to use DRM directly.
  - kaba0 5y ago
    Please have a look at an X maintainers very own presentation: https://m.youtube.com/watch?v=cQoQE_HDG8g https://m.youtube.com/watch?v=cQoQE_HDG8g Wayland is not a middle man as it is the compositor itself as well - it does the minimal amount of work necessary to compose the desktop. X on the other hand just transfers messages between clients and the compositor without doing any actual work (x render functions are almost never used by modern applications)
    - sprash 5y ago
      Many of the points of this talks are invalidated with the introduction of DRI3 others are still valid but Wayland is not a solution. The X server indeed "just transfers messages between clients" but so does a Wayland compositor. How else would a screen capture functionality even work. Also, the fact that GTK/QT applications don't use Xrender (GTK used to but dropped it) can not be blamed on X.
      - kaba0 5y ago
        Using xrender would pretty much result in terrible performance, not allowing the extreme parallelism of GPUs. This is the fundamental problem with X, it originates from a time when GPUs were not even a thing. It had a great run, but let it sleep now. Also, DRI3 doesn’t solve the fundamental security flaw of X - which can only be solved by nesting multiple X servers into each other. At that point we would have a much uglier architecture than we have with wayland.
        ttybird2 5y ago
        I am a bit confused. I do not think that hardware accelerated UI was a thing until quite recently and people did not really have issues with its performance. If anything it feels like that accelerated UI drawing is slower on older machines compared to software-rendered UI.
        kaba0 5y ago
        Well, try using any graphical application from inside a vm (those are often software accelerated only). But the problem is basically: you can either have 1-2-4-8 cores at most writing pixels into a buffer one after another (but due to the complexity of interactive GUIs it will most often be single threaded), so a circle will be displayed as going over an area and coloring each pixel. Versus specifying some condition and having the GPU run it on every pixel in large batches, almost doing it in one go. Of course for 3 lines, what previous GUI iterations were, you don’t need gpu, but for gradients, media!, and basically a bunch of other things you simply need the GPU’s orders of magnitude more parallelism. Add to the picture that we are using much bigger screen resolutions (full hd has 6x number of pixels compared to 480p, and then we are not even talking about 4k. And 120, 240fps monitors are a thing now) and you can quickly see that 1) drawing is a greatly parallelizable task 2) having it done serialized simply doesn’t scale to today screens.
- vidarh 5y ago
  Nothing stopped anyone from building a compositor into an X server if that is what you want to change.

by sprash 5y ago

kaba0 5y ago

Ncurses apps can also display GUIs for a long time now, but it doesn’t mean that they are actually good solutions. The X server became a pretty useless middle man between clients and the compositor. And the vastly changed GPU hardware is the reason we should prefer a superior solution - we no longer draw as we did 3 decades ago, so we should cut out the middle man.

sprash 5y ago
> Ncurses apps can also display GUIs Terminal applications stood the test of time as well. For everything that is not graphical in nature they are indeed good solutions. > The X server became a pretty useless middle man between clients and the compositor. X is a middle man but far from useless. Just as Wayland is a middle man as well. And looking at the protocol actual access to GPU memory is more opaque on Wayland than on X11 and as such to me Wayland is a more intrusive middleman. If you want to "cut out the middle man" you have to use DRM directly.
- kaba0 5y ago
  Please have a look at an X maintainers very own presentation: https://m.youtube.com/watch?v=cQoQE_HDG8g https://m.youtube.com/watch?v=cQoQE_HDG8g Wayland is not a middle man as it is the compositor itself as well - it does the minimal amount of work necessary to compose the desktop. X on the other hand just transfers messages between clients and the compositor without doing any actual work (x render functions are almost never used by modern applications)
  - sprash 5y ago
    Many of the points of this talks are invalidated with the introduction of DRI3 others are still valid but Wayland is not a solution. The X server indeed "just transfers messages between clients" but so does a Wayland compositor. How else would a screen capture functionality even work. Also, the fact that GTK/QT applications don't use Xrender (GTK used to but dropped it) can not be blamed on X.
    - kaba0 5y ago
      Using xrender would pretty much result in terrible performance, not allowing the extreme parallelism of GPUs. This is the fundamental problem with X, it originates from a time when GPUs were not even a thing. It had a great run, but let it sleep now. Also, DRI3 doesn’t solve the fundamental security flaw of X - which can only be solved by nesting multiple X servers into each other. At that point we would have a much uglier architecture than we have with wayland.
      - ttybird2 5y ago
        I am a bit confused. I do not think that hardware accelerated UI was a thing until quite recently and people did not really have issues with its performance. If anything it feels like that accelerated UI drawing is slower on older machines compared to software-rendered UI.
        kaba0 5y ago
        Well, try using any graphical application from inside a vm (those are often software accelerated only). But the problem is basically: you can either have 1-2-4-8 cores at most writing pixels into a buffer one after another (but due to the complexity of interactive GUIs it will most often be single threaded), so a circle will be displayed as going over an area and coloring each pixel. Versus specifying some condition and having the GPU run it on every pixel in large batches, almost doing it in one go. Of course for 3 lines, what previous GUI iterations were, you don’t need gpu, but for gradients, media!, and basically a bunch of other things you simply need the GPU’s orders of magnitude more parallelism. Add to the picture that we are using much bigger screen resolutions (full hd has 6x number of pixels compared to 480p, and then we are not even talking about 4k. And 120, 240fps monitors are a thing now) and you can quickly see that 1) drawing is a greatly parallelizable task 2) having it done serialized simply doesn’t scale to today screens.
vidarh 5y ago
Nothing stopped anyone from building a compositor into an X server if that is what you want to change.