4 ms·

> probably due to neglect Kinda yes kinda no? Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. So everyone draws stuff on

> probably due to neglect Kinda yes kinda no? Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. So everyone draws stuff on their own, since it's far more flexible and faster. Same is true on windows. RDP is streaming video far more often than it steams drawing commands. You could maybe build something that streams GPU commands, though. Use something like VirtIO-GPU + GFXSTREAM ( https://www.phoronix.com/news/VirtIO-Context-Type https://www.phoronix.com/news/VirtIO-Context-Type ) to stream to an entirely different computer instead of just to the VM host?

PaulDavisThe1st 4y ago
> Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. The two things that have changed are the underlying GPU technology, which has shifted towards abstractions and APIs mostly targetting gaming and video, and desktop level UI stuff, which is expected to include compositing these days. However, it's not as if the other remote desktop systems have really changed much to reflect these developments either.
- kllrnohj 4y ago
  > This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. This is really fundamentally wrong. Nobody has been updating X commands for modern effects (eg, blurs, advanced blend modes, etc..). Heck you can't even do round-rect clipping. You have to generate a clip mask pixmap instead. At which point I might as well just generate the final pixmap and forget about X anything. Especially since xlib doesn't even do anti aliasing. Like come the fuck on, it's friggin useless. Can't even handle text adequately! There's a reason Wayland dumped it all entirely. If it had been maintained and updated sure maybe. But it wasn't. It's a drawing library straight out of the 90s, absolute abandonware
  - PaulDavisThe1st 4y ago
    Well, on the one hand, you're right. But on the other hand, X is still being used to do all that stuff (not necessarily using the body of its drawing command set). So even if X's drawing commands themselves are less relevant than they once were, X itself is still entirely capable of presenting GUIs with blurs, anti-aliased text etc. etc.
    - kllrnohj 4y ago
      Well sure but it's just compositing pixmaps from somewhere else. It's just a bad compositor at this point
renox 4y ago
> so everyone draws stuff on their own, since it's far more flexible and faster Faster for which usage? Locally yes, but not remotely where it's worse.. In the beginning Unix desktops were optimised for LAN, and in the process of being optimised for standalone PCs to the dismay off those who access their Linux desktop remotely..
- kllrnohj 4y ago
  > Faster for which usage? Locally yes, but not remotely where it's worse.. How do you know it's actually worse for remote? I can render my entire UI on the GPU & route that straight into a video encoder incredibly quickly. Faster than XLib can draw in the first place. Now there's the bandwidth question there yeah. The video stream takes X Mbps, and the Xlib stream takes Y Mbps. Unless you've measured it recently, you don't actually know if X or Y is smaller. You can make a guess that xlibs is smaller, sure. After all it's vector, right? Except it isn't, not really. Text is all pixmaps. Images are all pixmaps. Path clipping is all pixmaps. Are you compressing all those pixmaps before sending? If so, to what? And is that faster than your GPUs h264 encoder? Almost certainly not. Is it smaller? Also probably not really. And I don't know about you, but I got way more bandwidth than I have latency for my Internet connection. So whether or not X or Y is smaller doesn't actually matter to me. What matters is which gives me less end to end latency, which all but certainly is the video encoder & decoder path, which are incredibly well optimized and hardware accelerated.
  - yjftsjthsd-h 4y ago
    > How do you know it's actually worse for remote? Because I've tried `ssh -X` and in my experience it sucks for any "modern" program (that I've used; I suppose there's bias in my sample).
jcelerier 4y ago
"everyone" is just not true, Qt apps can still send X11 draw commands
- tinus_hn 4y ago
  You can easily draw any desktop with X11 draw commands. They’ll just be Blit Blit Blit Blit Blit Blit Blit The x11 commands allow you to draw lines, ugly patterns, ugly fonts and blit pixmaps. All of them except blitting pixmaps are basically not useful for a modern desktop.
  - jcelerier 4y ago
    This is literally false for Qt. Here's the code: https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/xcb/nativepainting/qpaintengine_x11.cpp#L943 https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/... Here's e.g. dolphin rendered with it here over ssh: https://imgur.com/bLnop55 https://imgur.com/bLnop55 > All of them except blitting pixmaps are basically not useful for a modern desktop. that's ridiculous. Most software is basically a succession of drawLines / drawRect calls with the occasional pixmap.
    - kllrnohj 4y ago
      How much of that dolphin UI is hitting X drawing commands, which appears from your source link to be the simple case only, and how many are rendered to pixmaps and only composited by X? All of the text, for example, is rendered by QT and sent as pixmaps. The drawTextItem path doesn't ever attempt to use XDrawText
      - jcelerier 4y ago
        What simple case ? Every call to drawRect/drawLine that I can see at a glance will end up inside X functions - e.g. calls to QPaintEngine::drawRects will just end up in the function below. And that's the huge majority of the UI. Anyways, what matters to me is that I can resize the window without any lag and compression - it immediately becomes much more laggy and redraw-artefact-y if I disable X11 painting when I access my remote machines so it's pretty obvious when things are using it

PaulDavisThe1st 4y ago

> Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. The two things that have changed are the underlying GPU technology, which has shifted towards abstractions and APIs mostly targetting gaming and video, and desktop level UI stuff, which is expected to include compositing these days. However, it's not as if the other remote desktop systems have really changed much to reflect these developments either.

kllrnohj 4y ago
> This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits. This is really fundamentally wrong. Nobody has been updating X commands for modern effects (eg, blurs, advanced blend modes, etc..). Heck you can't even do round-rect clipping. You have to generate a clip mask pixmap instead. At which point I might as well just generate the final pixmap and forget about X anything. Especially since xlib doesn't even do anti aliasing. Like come the fuck on, it's friggin useless. Can't even handle text adequately! There's a reason Wayland dumped it all entirely. If it had been maintained and updated sure maybe. But it wasn't. It's a drawing library straight out of the 90s, absolute abandonware
- PaulDavisThe1st 4y ago
  Well, on the one hand, you're right. But on the other hand, X is still being used to do all that stuff (not necessarily using the body of its drawing command set). So even if X's drawing commands themselves are less relevant than they once were, X itself is still entirely capable of presenting GUIs with blurs, anti-aliased text etc. etc.
  - kllrnohj 4y ago
    Well sure but it's just compositing pixmaps from somewhere else. It's just a bad compositor at this point

renox 4y ago

> so everyone draws stuff on their own, since it's far more flexible and faster Faster for which usage? Locally yes, but not remotely where it's worse.. In the beginning Unix desktops were optimised for LAN, and in the process of being optimised for standalone PCs to the dismay off those who access their Linux desktop remotely..

kllrnohj 4y ago
> Faster for which usage? Locally yes, but not remotely where it's worse.. How do you know it's actually worse for remote? I can render my entire UI on the GPU & route that straight into a video encoder incredibly quickly. Faster than XLib can draw in the first place. Now there's the bandwidth question there yeah. The video stream takes X Mbps, and the Xlib stream takes Y Mbps. Unless you've measured it recently, you don't actually know if X or Y is smaller. You can make a guess that xlibs is smaller, sure. After all it's vector, right? Except it isn't, not really. Text is all pixmaps. Images are all pixmaps. Path clipping is all pixmaps. Are you compressing all those pixmaps before sending? If so, to what? And is that faster than your GPUs h264 encoder? Almost certainly not. Is it smaller? Also probably not really. And I don't know about you, but I got way more bandwidth than I have latency for my Internet connection. So whether or not X or Y is smaller doesn't actually matter to me. What matters is which gives me less end to end latency, which all but certainly is the video encoder & decoder path, which are incredibly well optimized and hardware accelerated.
- yjftsjthsd-h 4y ago
  > How do you know it's actually worse for remote? Because I've tried `ssh -X` and in my experience it sucks for any "modern" program (that I've used; I suppose there's bias in my sample).

jcelerier 4y ago

"everyone" is just not true, Qt apps can still send X11 draw commands

tinus_hn 4y ago
You can easily draw any desktop with X11 draw commands. They’ll just be Blit Blit Blit Blit Blit Blit Blit The x11 commands allow you to draw lines, ugly patterns, ugly fonts and blit pixmaps. All of them except blitting pixmaps are basically not useful for a modern desktop.
- jcelerier 4y ago
  This is literally false for Qt. Here's the code: https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/xcb/nativepainting/qpaintengine_x11.cpp#L943 https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/... Here's e.g. dolphin rendered with it here over ssh: https://imgur.com/bLnop55 https://imgur.com/bLnop55 > All of them except blitting pixmaps are basically not useful for a modern desktop. that's ridiculous. Most software is basically a succession of drawLines / drawRect calls with the occasional pixmap.
  - kllrnohj 4y ago
    How much of that dolphin UI is hitting X drawing commands, which appears from your source link to be the simple case only, and how many are rendered to pixmaps and only composited by X? All of the text, for example, is rendered by QT and sent as pixmaps. The drawTextItem path doesn't ever attempt to use XDrawText
    - jcelerier 4y ago
      What simple case ? Every call to drawRect/drawLine that I can see at a glance will end up inside X functions - e.g. calls to QPaintEngine::drawRects will just end up in the function below. And that's the huge majority of the UI. Anyways, what matters to me is that I can resize the window without any lag and compression - it immediately becomes much more laggy and redraw-artefact-y if I disable X11 painting when I access my remote machines so it's pretty obvious when things are using it