I imagine that historically, sending draw commands would have been highly efficient and quite responsive— show these form controls, this text field with these contents, etc. But as common use-cases have gotten more and more graphical, it's made more sense to just render a buffer and send that instead.
X11 forwarding essentially does that anyway nowadays. Modern toolkits don't actually use most of X11 because it's inefficient and unnecessary with the hardware we have.
And because the graphics primitives built into X11 are... well, primitive. The protocol was designed in the mid-1980s, at a point in time where display resolutions were low and color displays were usually limited to 256 colors or less. As a result, the graphics and text primitives don't support antialiased rendering or any kind of color blending -- so anything using those functions looks rather ugly and dated.
Nope, Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to ; I use it that way and it's pretty cool, last week I was debugging an app running on a raspberry pi behind a university proxy a few hundred kilometers away from home and it worked fine, and has the very nice benefit of using my .Xresources (e.g. for my local screen's hi DPI)
IIRC that only applies to Qt Widgets apps which is a decreasing number of apps. The XCB native painting flag doesn't work with Qt Quick and actually seems to break those apps which use it, because Qt Quick is rendered with GL. Someone correct me if I've got the details wrong here but for me that flag is pretty broken, it falls into the category of "legacy compatibility only" just like everything else in X11...
Yeah, because people were using that for some older Qt Widgets apps. AFAICT it was never supported for Qt Quick because that doesn't even use the Qt platform style.
Wtf. We really live in different worlds. Most programs you use in your desktop are not "toolbars-forms-dialogs-and-buttons" ? What exactly do you use ? Braille interface ?
Web browsers? Programs based around images/video? LibreOffice? Krita? Blender? Most "productivity" apps I see are based around a canvas or around images in some way. If they can hardware accelerate that, they will.
Except they aren't really, the main widget in all of those is already an OpenGL accelerated canvas... If your application is primarily a form or a dialog then yeah, but everything else that has images or video or custom drawing is going to want hardware acceleration. Maybe you spend a lot of time filling out forms or in text editors or writing emails? But I think even those text-based apps will want to be hardware accelerated eventually too, just look at the number of GPU rendered terminal emulators that are popping up.
- Telegram (Qt widgets, even if it does not look like it ;p)
- Firefox (its own thing, hardware-accelerated)
- VSCode (electron, hardware-accelerated)
My document-writing software is TeXStudio, also in Qt widgets. The main software I work on, https://ossia.io is too (the canvas can be rendered with Qt's GL painter but this leads to better performance only on 4K+ resolutions, on 2K Qt's software renderer is faster and has less latency in all the systems I could try, and has a way lower "idle" energy consumption as it does not particularly wake the GPU). Other than that, software that I use occasionnally are all widgets-based and don't do GPU rendering (AFAIK): LMMS, QLC+...
Anecdotally, I tried every GPU accelerated terminal I could find and none felt as good as my trusty old urxvt
> Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to
It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? In any case, if it can use server-side X11 painting, that doesn't mean that it doesn't support the opposite, which is what I meant -- unless the Qt devs completely removed the code for client-side rendering, it's basically already ready for that scenario (passing pixmaps), isn't it?
> and has the very nice benefit of using my .Xresources (e.g. for my local screen's hi DPI)
Not quite sure how that is relevant. Isn't it possible to query that from the client, then produce a pixmap in an appropriate resolution? That should be transparent.
> It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"?
I was talking about the flag.
Qt by itself can render however you want it to, if someone wanted to make a platform abstraction that would render Qt apps with ncurses that would be possible too.
> it's basically already ready for that scenario (passing pixmaps), isn't it?
sure, if you use it as a local X11 client (or on other platforms than X11) it's what happens too
I wonder, is this purely a compile-time thing, or is the Qt binary library capable of switching between the two depending on whether you have a remote display or not? It seems like something that should be possible without forcing you to choose whether the performance of local or remote users is prioritized with a compile-time switch.
yes, that's how a single Qt binary can run on wayland, x11, raw EGLFS, or even expose itself over VNC (https://doc.qt.io/qt-5/qpa.html)
you can force a platform with QT_QPA_PLATFORM=<...> with <...> being one of the plug-in names in your /usr/lib/qt/plugins/platforms
The only limit is that it can only be chosen on startup but not changed "while" the application runs if e.g. for some reason you wanted to switch a Qt app from X11 to wayland without restarting the app.
This clearly makes sense architecturally, but my goodness these envvars are a nuisance in Nix where you have wrapQtAppsHook and a bunch of other hackery to ensure that the proper plugins are findable at runtime.
