3 ms·

"And, I have also been reading the claims of programs going to switch to OpenGL 'any time soon' since the 2000s, with people backing out of the idea always due

by md8z 5y ago

"And, I have also been reading the claims of programs going to switch to OpenGL 'any time soon' since the 2000s, with people backing out of the idea always due to 'drivers' or the like." I really don't know what else to tell you. Like I said, GTK4 and Qt are already using it. Chrome/Electron is using it, and Firefox will have it very soon. Wayland didn't break anything here, that and improvements in the drivers were just the missing pieces to finally complete the transition. Really, developers have been trying to ditch X for an extremely long time, you just said you've been hearing them talk about it for 20 years. Well as you know it takes a long time to rebuild everything. "I was perusing the KDE source and the only program I could find is plasma-widgets" I can think of several: KDE Connect, KSysGuard, System Settings, Kamoso, Kongress, there are more but I can't remember all of them! And yes, the entire shell also uses QML and Qt Quick. "I use latest released version of Gnome and it is not." This happened in GNOME 40 so your distro may be behind. See some docs from like 6 months ago: https://gjs.guide/extensions/upgrading/gnome-shell-40.html#prefs https://gjs.guide/extensions/upgrading/gnome-shell-40.html#p... "i.e. ALWAYS when using X as backend. It is the default. What else are they going to use, the PostScript backend? " No, the image backend is probably what you would consider the default because it works everywhere and can be used for off-screen rendering. In my experience Cairo Xlib surfaces are actually pretty uncommon because client side operations are done so frequently.

AshamedCaptain 5y ago
> I really don't know what else to tell you. Like I said, GTK4 and Qt are already using it. Chrome/Electron is using it, and Firefox will have it very soon. Well, then don't repeat exactly the same argument. The point is that most desktop software _as of this day_ does not use client-side rendering, and even less desktop software uses OpenGL for rendering. Most of them are using plain classic widgets. We find some exceptions, but this is hardly enough to claim that most desktop software uses OpenGL, not in 2020, much less in 2000s. > I can think of several: KDE Connect, KSysGuard, System Settings, Kamoso, Kongress, While KDE Connect and Kongress do have some qml for the interface ( https://invent.kde.org/deepakarjariya/kdeconnect-kde/-/tree/master/app/qml https://invent.kde.org/deepakarjariya/kdeconnect-kde/-/tree/... ) , I have not been able to find any QML whatsoever for the rest (e.g. https://github.com/KDE/ksysguard https://github.com/KDE/ksysguard ). Kongress looks like a widget anyway. You can easily recognize these programs by how poorly they integrate with the rest of KDE, and I definitely do not see them with any frequency at all. > This happened in GNOME 40 so your distro may be behind. So, apparently, gnome-shell uses it through GJS, which is why I can't find any binary linking directly to gtk4. It's still literally one user. > No, the image backend is probably what you would consider the default because it works everywhere and can be used for off-screen rendering. The xlib backend is obviously also capable of off-screen rendering, otherwise all hell would break loose. And the xlib backend is still the default. Seriously: https://github.com/GNOME/gtk/blob/master/gdk/x11/gdksurface-x11.c https://github.com/GNOME/gtk/blob/master/gdk/x11/gdksurface-... . Why don't you just try? It's not hard to get into a situation where you don't have a working OpenGL environment and _all_ software still works. It's not hard to measure the bandwidth used for indirect X. Etc. Etc.
- md8z 5y ago
  There isn't anything else for me to say, and I am not arguing with you or presenting an argument, this is just a casual conversation. Most of the software I know about uses OpenGL or Vulkan for rendering, and the server side ones are the exception. I'm repeating it because it didn't seem like you were understanding what I was saying, if you did understand it then you can disregard the previous comment. You can tell me that you don't use that software, which is fine for you, and I'm happy for you to use whatever suits you, but it's not really a meaningful discussion for us to have either. Please avoid making such comments or suggesting that I don't know what I'm talking about. Of course I can't know exactly what is going on on your computer, so if you want to explain it, then just tell me. "I have not been able to find any QML whatsoever for the rest" You won't find some of the QML from looking at the apps, bits of it are scattered in the KDE frameworks too. I don't think they integrate poorly, work has been done to make them match the Breeze skin. "It's still literally one user." Yeah that was kind of a dry run for GTK4 porting. As I said before, everything else is being ported, the next step was to get the support libraries ported over and then everything else can follow. https://gitlab.gnome.org/GNOME/Initiatives/-/issues/26 https://gitlab.gnome.org/GNOME/Initiatives/-/issues/26 "The xlib backend is obviously also capable of off-screen rendering" You usually don't want to do that, it introduces unnecessary round trips when you could just render it on the client side and then avoid that. That link to gdk surface is misleading, even on X11, GTK4 is using the GL renderer as default and is not going to call that or bother creating a cairo surface. Believe me, I've tried this in a situation without a working OpenGL environment and the performance is degraded.

by md8z 5y ago

AshamedCaptain 5y ago

> I really don't know what else to tell you. Like I said, GTK4 and Qt are already using it. Chrome/Electron is using it, and Firefox will have it very soon. Well, then don't repeat exactly the same argument. The point is that most desktop software _as of this day_ does not use client-side rendering, and even less desktop software uses OpenGL for rendering. Most of them are using plain classic widgets. We find some exceptions, but this is hardly enough to claim that most desktop software uses OpenGL, not in 2020, much less in 2000s. > I can think of several: KDE Connect, KSysGuard, System Settings, Kamoso, Kongress, While KDE Connect and Kongress do have some qml for the interface ( https://invent.kde.org/deepakarjariya/kdeconnect-kde/-/tree/master/app/qml https://invent.kde.org/deepakarjariya/kdeconnect-kde/-/tree/... ) , I have not been able to find any QML whatsoever for the rest (e.g. https://github.com/KDE/ksysguard https://github.com/KDE/ksysguard ). Kongress looks like a widget anyway. You can easily recognize these programs by how poorly they integrate with the rest of KDE, and I definitely do not see them with any frequency at all. > This happened in GNOME 40 so your distro may be behind. So, apparently, gnome-shell uses it through GJS, which is why I can't find any binary linking directly to gtk4. It's still literally one user. > No, the image backend is probably what you would consider the default because it works everywhere and can be used for off-screen rendering. The xlib backend is obviously also capable of off-screen rendering, otherwise all hell would break loose. And the xlib backend is still the default. Seriously: https://github.com/GNOME/gtk/blob/master/gdk/x11/gdksurface-x11.c https://github.com/GNOME/gtk/blob/master/gdk/x11/gdksurface-... . Why don't you just try? It's not hard to get into a situation where you don't have a working OpenGL environment and _all_ software still works. It's not hard to measure the bandwidth used for indirect X. Etc. Etc.

md8z 5y ago
There isn't anything else for me to say, and I am not arguing with you or presenting an argument, this is just a casual conversation. Most of the software I know about uses OpenGL or Vulkan for rendering, and the server side ones are the exception. I'm repeating it because it didn't seem like you were understanding what I was saying, if you did understand it then you can disregard the previous comment. You can tell me that you don't use that software, which is fine for you, and I'm happy for you to use whatever suits you, but it's not really a meaningful discussion for us to have either. Please avoid making such comments or suggesting that I don't know what I'm talking about. Of course I can't know exactly what is going on on your computer, so if you want to explain it, then just tell me. "I have not been able to find any QML whatsoever for the rest" You won't find some of the QML from looking at the apps, bits of it are scattered in the KDE frameworks too. I don't think they integrate poorly, work has been done to make them match the Breeze skin. "It's still literally one user." Yeah that was kind of a dry run for GTK4 porting. As I said before, everything else is being ported, the next step was to get the support libraries ported over and then everything else can follow. https://gitlab.gnome.org/GNOME/Initiatives/-/issues/26 https://gitlab.gnome.org/GNOME/Initiatives/-/issues/26 "The xlib backend is obviously also capable of off-screen rendering" You usually don't want to do that, it introduces unnecessary round trips when you could just render it on the client side and then avoid that. That link to gdk surface is misleading, even on X11, GTK4 is using the GL renderer as default and is not going to call that or bother creating a cairo surface. Believe me, I've tried this in a situation without a working OpenGL environment and the performance is degraded.