4 ms·

I was under the impression that pretty much anything recent used client-side rendering anyway? For example, anything Qt based.

by jhgb 5y ago

jcelerier 5y ago
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)
- jhgb 5y ago
  > 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.
  - jcelerier 5y ago
    > 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
    - jhgb 5y ago
      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.
      - jcelerier 5y ago
        > is the Qt binary library capable of switching 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 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.
        jhgb 5y ago
        Heh, I completely forgot about the ability to switch between Wayland/X11 session which makes this necessary in the first place anyway. Cool, thanks, I learned something new. > or even expose itself over VNC (https://doc.qt.io/qt-5/qpa.html https://doc.qt.io/qt-5/qpa.html) Hmmm, I wonder how difficult it would be to support Ultimate++'s TURTLE protocol (https://www.ultimatepp.org/reference$WebWord$en-us.html https://www.ultimatepp.org/reference$WebWord$en-us.html)...
        mikepurvis 5y ago
        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.
- md8z 5y ago
  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...
  - AshamedCaptain 5y ago
    Actually the flag was added in some Qt 5.x version due to outcry.
    - md8z 5y ago
      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.
      - AshamedCaptain 5y ago
        Going to ask: do you know _any_ desktop software using Qt Quick ?
        md8z 5y ago
        Yes. KDE has been slowly adopting it for 11 years (!) now: https://aseigo.blogspot.com/2010/10/plasma-in-18-24-months.html https://aseigo.blogspot.com/2010/10/plasma-in-18-24-months.h...
        jcelerier 5y ago
        As a data point the immense majority of apps I use are still widgets.
        md8z 5y ago

I was under the impression that pretty much anything recent used client-side rendering anyway? For example, anything Qt based.

by jhgb 5y ago

I was under the impression that pretty much anything recent used client-side rendering anyway? For example, anything Qt based.

jcelerier 5y ago

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)

jhgb 5y ago
> 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.
- jcelerier 5y ago
  > 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
  - jhgb 5y ago
    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.
    - jcelerier 5y ago
      > is the Qt binary library capable of switching 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 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.
      - jhgb 5y ago
        Heh, I completely forgot about the ability to switch between Wayland/X11 session which makes this necessary in the first place anyway. Cool, thanks, I learned something new. > or even expose itself over VNC (https://doc.qt.io/qt-5/qpa.html https://doc.qt.io/qt-5/qpa.html) Hmmm, I wonder how difficult it would be to support Ultimate++'s TURTLE protocol (https://www.ultimatepp.org/reference$WebWord$en-us.html https://www.ultimatepp.org/reference$WebWord$en-us.html)...
      - mikepurvis 5y ago
        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.
md8z 5y ago
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...
- AshamedCaptain 5y ago
  Actually the flag was added in some Qt 5.x version due to outcry.
  - md8z 5y ago
    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.
    - AshamedCaptain 5y ago
      Going to ask: do you know _any_ desktop software using Qt Quick ?
      - md8z 5y ago
        Yes. KDE has been slowly adopting it for 11 years (!) now: https://aseigo.blogspot.com/2010/10/plasma-in-18-24-months.html https://aseigo.blogspot.com/2010/10/plasma-in-18-24-months.h...
        jcelerier 5y ago
        As a data point the immense majority of apps I use are still widgets.
        md8z 5y ago