The Current State & Future Of GTK's New Unified Renderers

[mangeek]

I thought GTK+ switched from GL to NGL a while ago, but was working on fixing some bugs with Vulkan. Maybe I misunderstood that for the last few years.

[Myownfriend]

This bit is not accurate. what you are seeing is the effects of a post release version bump - you are seeing the version in the format of something like 4.13.7-githash. that last part will be dropped when the actual release is being tagged.

Thanks for the clarification!

However I must say this forum topic has shown a type of bias against gtk/gnome which is not based on reality. The number of bad faith takes is unreal.

Absolutely. The Gnome Project gets unnecessarily shit on by a lot of people. They have this assumption that it's an insular community that doesn't like outsiders, are racist against white people, don't know what they're doing, aren't aware of the world around them, and are tyrants. It's ridiculous. There's an interview with a Gnome dev on Tech Over Tea where he talks about he had to get off social media because the amount of harassment he was receiving. People doxed him and even threatened to kill his daughter. He said it happens to a lot of Linux developers but the host had pointed out that Gnome developers definitely get a large part of it.

This is not even a stable release of gtk, it is a development release.

I had thought this was the case but didn't want to say it without knowing for sure.

[You-]

I thought GTK+ switched from GL to NGL a while ago, but was working on fixing some bugs with Vulkan. Maybe I misunderstood that for the last few years.

There was a stable release with both the original GL and the NGL renderers present. That release made the "ngl" name a part of the API contract, so when the original GL renderer was removed and the NGL was renamed to GL, some public API calls to ngl could not be removed.

As fortune would have it, due to those "accidents", it was easy possible to wire up the new (new) GL renderer as ngl. Chances are the new ngl renderer will live on alongside the older ngl renderer until atleast 4.16 and maybe even much longer as is currently covers a few use cases that are not fully covered by the new ngl renderer quite yet.

[Daktyl198]

However I must say this forum topic has shown a type of bias against gtk/gnome which is not based on reality. The number of bad faith takes is unreal.

This is the case with every open source project mentioned on the Phoronix forums, it's not a bias against Gnome specifically. The Linux community has favorites, and they HATE anything that isn't their favorite. Look at any release about KDE/Plasma, or even simple window managers. You'll find people in every thread spouting stuff that may or may not be true, but ends up being vitriolic.

For Gnome it's "The developers are stuck-up/don't listen to outside opinions/break extensions every single release"
For KDE it's "Development is too slow, it's too buggy" among other things.
For stuff like Sway it always starts an argument about Wayland, where bad-faith takes get thrown around about both Wayland and X.org.

[Daktyl198]

Gnome extensions aren't a hack. There is an extension infrastructure that even they use for some officially maintained extensions. They're also the one's providing the documentation on how to make them and the Gnome extensions page is run by them.

And yet, my point about them not correctly implementing a proper depreciation period is true. Extensions still manage to break every other point release even with active developers. I distinctly remember a wave of extension developers giving up a year or so ago because it was too much trouble having to fix your extension almost every other point release. An available API does not mean they care about 3rd party extension developers. They update their own extensions when they update the API, and let 3rd party devs figure it out post release.

3rd party devs could just watch the extensions api git like a hawk for API changes (and afaik some do), but that's a lot of work for a free project just to work around the fact that the project you're extending doesn't know what "depreciation" means.

That's incorrect. They're against distributions applying themes because they wind up getting issues opened for problems that stem from the distributions theme. They're fine with user's applying themes because the user's would know what is being broken by the theme. The way that you apply themes is via Gnome Tweaks which is made and maintained by the Gnome Project.

I double checked myself, and it does seem this is correct. I take back what I said here regarding themes.
As for Gnome Tweaks, it is very frowned upon to use it in the Gnome space, from what I've seen. There's a reason they've separated all of those settings out of the Settings app. They keep it around because they'd be lambasted if they didn't, but they'd really prefer you not to use it.

I don't think you've done a good job using the previous statements to back this one up.

I am just a bad speaker/writer. I'm basing everything I know off of historical instances, and years of running Gnome for myself. The reality is that Gnome devs develop inside and for their own ecosystem, and don't care about breaking anything 3rd party. The only exception to this that I know of is GTK, as that is explicitly intended for 3rd parties to use. There, they properly depreciate features over the course of several releases, and give devs a chance to update without breakages.

As far as I can tell, they're not considering it experimental but they aren't committing to it as the default. That's why they said:

"In the just-released 4.13.6 snapshot, we have made the ngl renderer the new default. This is a trial balloon — the renderers need wider testing with different apps too verify that they are ready for production. If significant problems appear, we can revert back to the gl renderer for 4.14."

In that quote you just put, they said they are making the new NGL renderer the default. I never said anything about committing to it. They may indeed roll it back if necessary in the next point release, but how long will it be between point releases where the new NGL renderer might be continuously broken on a new system? You can switch back, but that requires the user to both be aware that the renderer updated randomly, and how to fix it. And that requires a working system to google the symptoms they may be having, since I doubt most users keep a close eye on the Gnome point release notes.

What does or doesn't make sense to do depends on how stable the renderer was shown to be before the merge. Considering the NGL renderer was written for correctness and was found to be less prone to rendering distortions, they seem pretty confident. The majority of the issues that have been opened up since doing this have been resolved already. If more major ones arise then they'll just change the default back in 4.14. No biggy.

I'm confident the new renderer is much better than the old one in a ton of ways, I just think it's far too early to be making it the default (on a point release, no less), rather than adding it in and letting people opt into it to test it with a menu setting.

And for the record, I like Gnome as a desktop these days, minus a couple issues (like no system tray). I even use it right now on my Linux drive. It's not like I'm trying to say the Gnome project is bad or they do things wrong, I'm just pointing out the way they do things. Gnome developers have a strong vision, and they don't let 3rd parties influence that at all. Part of that is extremely tight integration of their own ecosystem.

[Vermilion]

And yet, my point about them not correctly implementing a proper depreciation period is true. Extensions still manage to break every other point release even with active developers. I distinctly remember a wave of extension developers giving up a year or so ago because it was too much trouble having to fix your extension almost every other point release. An available API does not mean they care about 3rd party extension developers.

Your statement shows a lack of understanding of how extensions work in GNOME. There is NO extension API. Extensions work by live patching GNOME Shell JS code, which means they can change anything in the Shell UI, but also break whenever the specific GNOME Shell code changes. Extension developers know which parts of Shell code their extensions affect, and for testing and porting period there's the last stages of every GNOME development cycle (the freeze and .alpha/.beta/.rc releases).

(This is how old Firefox addons also used to work, the alternative is the much more limited but stable WebExtensions API that dictates what addons can and cannot do).

They update their own extensions when they update the API, and let 3rd party devs figure it out post release.

3rd party devs could just watch the extensions api git like a hawk for API changes (and afaik some do), but that's a lot of work for a free project just to work around the fact that the project you're extending doesn't know what "depreciation" means.

The rest is based on your speculations and bad faith, not facts.

[Myownfriend]

And yet, my point about them not correctly implementing a proper depreciation period is true. Extensions still manage to break every other point release even with active developers. I distinctly remember a wave of extension developers giving up a year or so ago because it was too much trouble having to fix your extension almost every other point release. An available API does not mean they care about 3rd party extension developers. They update their own extensions when they update the API, and let 3rd party devs figure it out post release.

3rd party devs could just watch the extensions api git like a hawk for API changes (and afaik some do), but that's a lot of work for a free project just to work around the fact that the project you're extending doesn't know what "depreciation" means.

The word is "deprecation" btw.

How would you recommend they deprecate things when part of what breaks them is changes in Gnome Shell, for example? Every release there is going to be some changes to the actual interface and considering many extensions insert themselves into the Quick Settings, for example, they really can't do anything to make that better for extension developers except to work slower.

As for Gnome Tweaks, it is very frowned upon to use it in the Gnome space, from what I've seen. There's a reason they've separated all of those settings out of the Settings app. They keep it around because they'd be lambasted if they didn't, but they'd really prefer you not to use it.

One of their recent initiatives has been to move some of the stuff from Tweaks back into Gnome Settings.

I am just a bad speaker/writer. I'm basing everything I know off of historical instances, and years of running Gnome for myself. The reality is that Gnome devs develop inside and for their own ecosystem, and don't care about breaking anything 3rd party. The only exception to this that I know of is GTK, as that is explicitly intended for 3rd parties to use. There, they properly depreciate features over the course of several releases, and give devs a chance to update without breakages.

Other than extensions, can you provide some other examples of them really not caring about 3rd parties? I don't see how Gnome devs develop for their own ecosystem anymore than people from other projects? KDE devs are you going to overwhelmingly be develop for KDE related things.

In that quote you just put, they said they are making the new NGL renderer the default. I never said anything about committing to it. They may indeed roll it back if necessary in the next point release, but how long will it be between point releases where the new NGL renderer might be continuously broken on a new system? You can switch back, but that requires the user to both be aware that the renderer updated randomly, and how to fix it. And that requires a working system to google the symptoms they may be having, since I doubt most users keep a close eye on the Gnome point release notes.

I'm confident the new renderer is much better than the old one in a ton of ways, I just think it's far too early to be making it the default (on a point release, no less), rather than adding it in and letting people opt into it to test it with a menu setting.

As You- said, this is a development release, not a widespread release that will make their way to any distributions. Think of it as a beta.