3 ms·

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

by 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.
    - ttybird2 5y ago
      "try using any graphical application from inside a vm" This is because said graphical applications are designed to be used with a modern GPU and they use stuff like OpenGL to render their components. "but for gradients" Maybe we can go without them. Modern UIs are too heavy, latency-inducing, battery consuming, and can turn your device into a heater easily. "And 120, 240fps monitors are a thing now" Re-drawing the window in every frame is a wasteful action that tends not to happen with applications designed for software rendering.
      - kaba0 5y ago
        The drawing lib used by chrome is ridiculously performant - the problem is not at lower layers in case of modern UIs. Specific hardware will also be much more efficient than general purpose one, so no, gpus are not the culprit behind any of those. While you may not like gradients, animations (which absolutely mandate GPUs) for example do give context on what happens because humans are used to physical objects that don’t teleport from one place to another. I wouldn’t consider these needless features either.
eptcyka 5y ago
Who uses XRender? If nobody is using XRender, is it because everyone is wrong or is it because XRender is not the best solution to the problem it's trying to solve today? And sure, X just transfers messages between clients, and the window manager is just a client, but it feels like X is redundant here - why not have a unified protocol so that the clients can talk to the window manager directly? That way, the window manager can actually delegate different functionality using some kind of an authentication mechanism. X was developed when the principle of least privilege wasn't as prevalent and it shows. I don't want all of my applications to be able to capture all of my screens at all times. Yet with X, there's no way to prevent this. And, may I ask,why are you so quick to dismiss the core developers of X?

by sprash 5y ago

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.
  - ttybird2 5y ago
    "try using any graphical application from inside a vm" This is because said graphical applications are designed to be used with a modern GPU and they use stuff like OpenGL to render their components. "but for gradients" Maybe we can go without them. Modern UIs are too heavy, latency-inducing, battery consuming, and can turn your device into a heater easily. "And 120, 240fps monitors are a thing now" Re-drawing the window in every frame is a wasteful action that tends not to happen with applications designed for software rendering.
    - kaba0 5y ago
      The drawing lib used by chrome is ridiculously performant - the problem is not at lower layers in case of modern UIs. Specific hardware will also be much more efficient than general purpose one, so no, gpus are not the culprit behind any of those. While you may not like gradients, animations (which absolutely mandate GPUs) for example do give context on what happens because humans are used to physical objects that don’t teleport from one place to another. I wouldn’t consider these needless features either.

eptcyka 5y ago

Who uses XRender? If nobody is using XRender, is it because everyone is wrong or is it because XRender is not the best solution to the problem it's trying to solve today? And sure, X just transfers messages between clients, and the window manager is just a client, but it feels like X is redundant here - why not have a unified protocol so that the clients can talk to the window manager directly? That way, the window manager can actually delegate different functionality using some kind of an authentication mechanism. X was developed when the principle of least privilege wasn't as prevalent and it shows. I don't want all of my applications to be able to capture all of my screens at all times. Yet with X, there's no way to prevent this. And, may I ask,why are you so quick to dismiss the core developers of X?