Ubuntu 20.04 LTS To Optimize GNOME For Fast/Modern PCs, Ubuntu 20.10 For Slow/Older PCs

[Guest]

What I "hear" when I read this, is that you will need a fast machine to have gnome work properly on 20.04 ...

You probably need at least a 5GHz modern CPU to have GNOME run at bearable speeds anyway. If Cannonical wants people to hate GNU/Linux, using GNOME is a great way to accomplish their questionable goals.

[GrayShade]

You probably need at least a 5GHz modern CPU to have GNOME run at bearable speeds anyway. If Cannonical wants people to hate GNU/Linux, using GNOME is a great way to accomplish their questionable goals.

At least he's honest about it:

To do this we first need to fix all real time delay issues. Because those might hurt you the same even with an infinitely fast CPU and GPU. You should be able to upgrade your hardware and actually experience some improvement.

(emphasis mine)

I'm glad Canonical is working on Gnome performance because it used to be a mess, and nobody seemed to care much. Even Daniel got a lot of pushback from Gnome developers who kept doubting the performance numbers he showed (without testing his changes) and removing the "performance" label from his merge requests.

[arQon]

I think people may misinterpret this as being about GNOME Shell, when it isn't, and TFA does stress that.

Aside from this

Seems backwards. The LTS should be optimized for slow machines and 20.10 for fast machines.

which is pretty clearly true, the problem is simply "bad code is bad". That's all there is to it. And the "bad code" in question here is GTK3 and its supporting pieces.

Updating a (fairly low-powered) machine running MATE (i.e. GTK-based, but not using GNOME Shell) from 16.04 to 19.10, if you change to a workspace with just 3 windows on it you can now see each one being painted in turn over what must be several hundred ms total, whereas under GTK2 the same switch was instant. Short of something incredibly stupid like a vsync wait on each region update, this points at a fundamentally broken design and/or implementation of the pipeline, and one that's still THAT broken even 5 years into GTK3.

GNOME Shell *itself* clearly has its own implementation issues on top of that, like the comedy gold linked in TFA, but the entire underlying architecture is also basically just broken, and the idea that it might be possible to pay off all that debt in just a few months is delusional.
"Make it fast on fast machines" is basically an acceptance of that, relying on horsepower to try to patch over the systemic issues once the Top X "LOL, IDK wut im doing!" bugs are fixed. And yeah, that's probably somewhat realistic as a goal.

"Make it fast on slower machines" though? That's never going to happen. If the GNOME team had the skill and desire to fix things, they'd have already done so. Since they haven't, even if Canonical does actually fix the problems they'll never get more than that first handful of patches accepted upstream. It's not "interesting" to the CADT, and that work will simply wither and die in the GNOME bugtracker before being RESOLVED OBSOLETE a few revisions from now, like hundreds of other GTK3 issues before it.
"This won't be a problem when we switch to Wayland". "This will be better in the upcoming GNOME Shell 5". "GTK4 should fix this". "We're not going to put resources into this because XYZ will replace Mutter / Clutter / whatever next year anyway".

I'd like to be proven wrong, and maybe I will be, but with so much evidence to the contrary I think I'll just wish Van Vugt luck and not hold my breath...

[royce]

I'm glad Canonical is working on Gnome performance because it used to be a mess, and nobody seemed to care much. Even Daniel got a lot of pushback from Gnome developers who kept doubting the performance numbers he showed (without testing his changes) and removing the "performance" label from his merge requests.

Indeed. You would think the developers whose code created the problems in the first place would be more humble, but the opposite is true. They've been blocking Daniel's work from day one with open hostility. Most of the work in gnome 3.34 could've been in 3.30 if it wasn't for gnome core developer's dithering on issues as vital as commit messages and variable names just for the sake of pushing back.

At this point, gnome would be better off reimplementing their DE over wlroots instead of fixing the spaghetti bowl mutter is.

[GrayShade]

And you don't know about the Gnome 3.34 Wayland clipboard issues :-).

At this point, gnome would be better off reimplementing their DE over wlroots instead of fixing the spaghetti bowl mutter is.

Sure, in Gnome Shell 5, but there are no plans to work on it right now /s.

[Britoid]

Indeed. You would think the developers whose code created the problems in the first place would be more humble, but the opposite is true. They've been blocking Daniel's work from day one with open hostility. Most of the work in gnome 3.34 could've been in 3.30 if it wasn't for gnome core developer's dithering on issues as vital as commit messages and variable names just for the sake of pushing back.

At this point, gnome would be better off reimplementing their DE over wlroots instead of fixing the spaghetti bowl mutter is.

If most of the work that went into 3.34 was put into 3.30 in the state it was in, we'd end up with a shell with a ton of regressions. His work also touched on areas that was already being worked on.

I'm glad Canonical is working on Gnome performance because it used to be a mess, and nobody seemed to care much. Even Daniel got a lot of pushback from Gnome developers who kept doubting the performance numbers he showed (without testing his changes) and removing the "performance" label from his merge requests.

That is a gross misinterpretation of what happened and a lie.

Only GNOME Developers (reminder, Daniel is not a GNOME dev) can attach labels to MRs, this is pretty normal and allows them to manage merge requests properly. He tried to go around this by placing labels in the title and attaching it to MRs that didn't impact performance, which put outside pressure on the GNOME maintainers to merge the request without proper scrutiny and testing, that wasn't fair.

GNOME Shell didn't have really any meaningful way of finding the cause of performance problems until fairly recent, his MRs often relied on checking CPU usage in top and trying to lower it, which he even admits in this post was a mistake.

[Mario Junior]

Maybe rewriting gnome from zero solves the problem.

[GrayShade]

That is a gross misinterpretation of what happened and a lie.

It's certainly not, and all of the things I mentioned have happened. I can't provide references because of the awful GitLab MR UI and being too slow in general for me to want to trawl through.

Yes, he's not a Gnome developer, Daniel did for the Gnome performance more than anyone else, and what did he get? Complaints that his performance numbers look too good to be true?

[Britoid]

It's certainly not, and all of the things I mentioned have happened. I can't provide references because of the awful GitLab MR UI and being too slow in general for me to want to trawl through.

You can't provide references because you're lying. Performance is regularly discussed on the GNOME Matrix/IRC channels, at GUADEC and the various Hackfests. He wasn't at them, so to randomly get a MR out the blue that works on something that was already actively being worked on, then to add fake [performance] labels to them without proper benchmarking and then have people creating Gitlab accounts to throw insults at the GNOME maintainers for not merging them isn't right. I give that the latter isn't Daniels fault, but the [performance] tags in the title didn't help.

GNOME devs do care about performance and do appreciate the work he does, he's great at finding problems and working on a compositor is no easy challenge. But GNOME is a community project that's ultimately deployed in commercial settings, MRs need to be scrutinized and work needs to be communicated.

[GrayShade]

You can't provide references because you're lying. Performance is regularly discussed on the GNOME Matrix/IRC channels, at GUADEC and the various Hackfests. He wasn't at them, so to randomly get a MR out the blue that works on something that was already actively being worked on, then to add fake [performance] labels to them without proper benchmarking and then have people creating Gitlab accounts to throw insults at the GNOME maintainers for not merging them isn't right. I give that the latter isn't Daniels fault, but the [performance] tags in the title didn't help.

GNOME devs do care about performance and do appreciate the work he does, he's great at finding problems and working on a compositor is no easy challenge. But GNOME is a community project that's ultimately deployed in commercial settings, MRs need to be scrutinized and work needs to be communicated.

Gnome dev caring more about 3D windows than a 2x CPU usage reduction (note % vs. pp, and the overall results hidden in a subthread at https://gitlab.gnome.org/GNOME/mutte...#note_586419):

Endless has an entire produce built around flipping a window and hacking it. Unless it is collectively agreed that reducing CPU usage by 7% is more important, I strongly oppose to that.

[...]

Go ahead then. I don't know why I even bother to help anymore.

[...]

I'm a bit skeptical of those CPU numbers. How did you measure them?

The whole https://gitlab.gnome.org/GNOME/mutte...e_requests/189 thread is very painful to read.