Hacker News Reader

Comment by sprash | Hacker News Reader

> x11 was designed around assumptions that are no longer correct

Nothing could be further from the truth. If you use Xrender properly you can make very sophisticated drawing operations that are extremely efficient over the wire and that are GPU accelerated even when the process does not run on the local machine.

It is Gtk and Qt that for wahtever reason decided to ditch their Xrender backends.

> multiple round-trips

This is also a problem introduced by badly designed tool-kits like Gtk and Qt. It is trivial to design tool-kits in X11 that require no round-trips.

> It just seems completely pointless to even bother with something x11's network transparency

This is mostly true because desktop software on Linux is mostly written by highly incompetent developers that produced abominations like Gtk3+.

View on HN

> It is Gtk and Qt that for wahtever reason decided to ditch their Xrender backends.

It was often slower and more likely to run in to driver issues than just doing software rendering and sending pixmaps. They're now moving to GL and Vulkan because they can be faster and while they have the same risk of driver issues at least that's the same stack used for video games and CAD and such so more people care about it working well.

> It was often slower

Any data on this? I can remember that your typical Cairo backend ran much faster on a PC from 2004 than todays GNOME/Gtk runs on current machines. If performance is your only argument you clearly lose with the modern GNOME/KDE + wayland stack. The only way you could make GLAMOR accelerated Xrender faster is by putting the spline tesselation step into a shader. (This was not possible when Xrender was introduced but can be done today without breaking any APIs)

This. I remember KDE3 being fast as hell doing 2D with a GeForce2 MX, much faster than a Geforce 8200 trying to run a similar rendered desktop but with OpenGL doing Xrender's job.

I saw a breakdown of how the X11 protocol over a network works (IIRC It was by one of the wayland proponents who also was a an xorg maintainer so he knew what he was talking about).

The protocol was very poorly designed everything needed essentially several trips back and forth between the client and server. That applies also if you're using Athena or motif widgets, it just becomes much worse with QT or gtk because they also transmit bitmaps, because otherwise they can't guarantee the look.

So it's latency not bandwidth which kills the performance. If you need 3 or 4 roundtrips just moving a window around, that's fine on your home network where you have a ping of 10ms, over the Internet with 100ms latency 3 roundtrips become 300ms so just a cursor move becomes painful.

You cannot say a developer is highly incompetent if you yourself do not have the ability to be at least as incompetent as them.

I agree there are problems with various stacks and widgets, but it isn't going to change anytime soon. At the end of the day, it requires someone who can create something from scratch, and those people are few and far between due to the amount of vision and work required. Especially if it's a non-paying task.

Most of your comment is pretty bad misinformation. X11 was not designed to use Xrender. That was an optional extension that came later. And on many drivers, the drawing of XRender is still not actually GPU accelerated either. Remember that XRender was designed long before GPU drivers were in the state they are now, back in the era when people still thought 2D acceleration was going to be a thing. And, XRender is extremely limited to a small handful of primitives that were mainly used to implement the postscript drawing model used by cairo.

It is also not trivial to reduce the amount of roundtrips in an X11 program. If the program uses Xlib then it probably needs to have significant portions of it rewritten to use xcb, which is a lot more complicated than it seems because Xlib handles a lot of caching and logic that xcb simply does not. In some situations X11 roundtrips are simply unavoidable. Complaining about GTK or Qt will not change this. Even if it were possible to fix those, there are less and less contributors to those projects who are willing to spend time to maintain X11 support.

Qt didn't ditch it. I use it all the time. If you have Debian it's compiled-in by default - just set QT_XCB_NATIVE_PAINTING=1

That flag has been broken for years: https://bugreports.qt.io/browse/QTBUG-70387

I doubt it will ever be fixed, because it offers no benefits when the application itself uses actual hardware rendering with GL or Vulkan. XCB can't speed that up at all.

...? the bugreport you pasted seem to have been fixed and merged 3 years ago.

The vast, vast, vast majority of the apps i use daily don't do any GPU rendering, just plain classic widget-based productivity apps

Sorry, I didn't clarify. The bug was fixed with some use of pixmaps, in other situations it's still broken.

It sounds like the vast majority of apps you use are very old. Even plain productivity apps benefit from GPU rendering. If they don't it's because those apps are far behind, compare to things like Electron apps where everything has been GPU accelerated for quite some time because of Skia.

I find electron apps absolutely horrendous to use. The apps I use most are Zim, QtCreator, Strawberry, and the KDE apps: Okular, etc. - most of the time when I remote ssh it's for pavucontrol-qt, dolphin (the file manager) or mainly the app I develop, https://ossia.io (for instance for working on a show that is taking place over a raspberry pi). None of those force any kind of GPU rendering.

Also apps that do gpu rendering make my laptop really heat up and loose battery quickly compared to when it's not in use - I don't use a compositor partly for this (+ the occasional frame lag)

That's not really relevant. You can personally choose to not use Electron apps, but many people cannot or do not want to choose to do that. Like it or not, it's a thing now. I've noticed a lot of developers seem to have this confusion that anyone else can avoid Electron. I guess you can if you spend all day in the terminal and the IDE but most other people cannot.

And that sounds like something is seriously wrong with your machine or your drivers. GPU rendering has massively improved performance and battery life on every machine I've ever tried. And especially on embedded devices with a low power mobile GPU, see for example here: https://social.librem.one/@dos/104984930233748319

Compositing should do so as well by avoiding unnecessary redraws. That sequencer would probably benefit greatly on a Raspberry by using GPU rendering, the screenshot even shows it rendering video and shaders...

> Compositing should do so as well by avoiding unnecessary redraws.

I use a tiling WM so I doubt it would help much. If anything, if I run a whole system profile with perf, rendering does not even show up when compared to just running a git status here.

> That sequencer would probably benefit greatly on a Raspberry by using GPU rendering, the screenshot even shows it rendering video and shaders...

Sure, the video & shader parts use GPU of course. But for the main GUI, it can be rendered with OpenGL or with Qt's software renderer ; from my tests (and lord knows I've spent entire weeks profiling and doing everything I could to improve rendering performance) the OpenGL backend for the main GUI only becomes more worth it when using a 4k resolution - and GL is absolutely full of bugs on e.g. windows ; yes there are still people with GMA500 GPUs. Qt's software renderer has no issue rendering at a 1080 screen size on a Pi 3.

Unless you are writing applications using motif and/or contributing to a better remote X11 experience, the why and how do not really matter if most popular applications are using GTK/QT and electron.

It was really nice and convenient at the time but it is going the way of the dodo the same way cars with manual gearbox are because almost nobody cares and there are other ways to connect remotely.

Reply on news.ycombinator.com