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

[Britoid]

Britoid, maybe you know, is anyone at Gnome team have plans for Gnome OSK improvements? (Onboard from year 2017 is still much, much more usable, but not available in Wayland session.) Or maybe at least make fractional scaling available on HD displays, and make higher scaling (225%, 250%, 275%, 300%) available for HiDPI displays? (Like HP Pro Tablet 608 G1, 8 inch, 2048x1536, 200% is clearly not enough.) All bugreports is filled, I don't pressure anyone, and patiently waiting. Just hope maybe you have some information about these issues.

I don't know of any work on the OSK but I agree the OSK is in a pretty bad state.

Imho https://extensions.gnome.org/extensi...reen-keyboard/ sort of functionality should be mainlined. The Purism people are also working on an OSK that's for their phones that could end up coming to desktops and is independent of the shell.

[RussianNeuroMancer]

Britoid, maybe you know, is anyone at Gnome team have plans for Gnome OSK improvements? (Onboard from year 2017 is still much, much more usable, but not available in Wayland session.) Or maybe at least make fractional scaling available on HD displays, and make higher scaling (225%, 250%, 275%, 300%) available for HiDPI displays? (Like HP Pro Tablet 608 G1, 8 inch, 2048x1536, 200% is clearly not enough.) All bugreports is filled, I don't pressure anyone, and patiently waiting. Just hope maybe you have some information about these issues.

[rastersoft]

Maybe rewriting gnome from zero solves the problem.

Fine. When will you start to do it? :-P

[Britoid]

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):

Yes, because GNOME Shell isn't the only user of Mutter and it's a supported feature. People seem to complain when GNOME removes something then complain when they don't.

A solution was eventually found that didn't rely on breaking implementations and was eventually backed up by proper performance statistics, rather than unreliable numbers.

[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.

[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]

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?

[Mario Junior]

Maybe rewriting gnome from zero solves the problem.

[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.

[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.