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

[gedgon]

[...] and removing the "performance" label from his merge requests.

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

It's not a lie, and here's a proof.

The difference w/ and w/o !719 is night and day. FPS for an overview animation @4k w/ GPU clocks forced to the lowest settings:

mutter-3.34.1+27+g85f5db7e7 w/o !719

*** FPS for MetaStage: 31 ***
*** FPS for MetaStage: 36 ***
*** FPS for MetaStage: 31 ***
*** FPS for MetaStage: 31 ***
*** FPS for MetaStage: 35 ***
*** FPS for MetaStage: 31 ***
*** FPS for MetaStage: 31 ***
*** FPS for MetaStage: 34 ***

mutter-3.34.1+27+g85f5db7e7 w/ !719

*** FPS for MetaStage: 60 ***
*** FPS for MetaStage: 60 ***
*** FPS for MetaStage: 61 ***
*** FPS for MetaStage: 60 ***
*** FPS for MetaStage: 61 ***
*** FPS for MetaStage: 60 ***
*** FPS for MetaStage: 61 ***
*** FPS for MetaStage: 61 ***

So, yeah. This MR definitely doesn't deserves a performance label. /s

[Raka555]

How is Arcan coming along ?

Guest You didn’t test 3.34/35 and you clearly didn’t read vanvugt’s blog.

That's because I have no interest in running GNOME, and my experiences with it are incidental.

[finalzone]

I'm guessing not so much the distribution, but probably due to the extra extensions that Ubuntu install on their Gnome release by default. Whereas I think Fedora and Debian and others just have a straight setup of Gnome-shell.

Indeed the extra extensions on Ubuntu Gnome session may be the culprit which means the issue still remains specific to the distribution for bundling them. Fedora has a plain Gnome Shell Wayland session in addition on Gnome Classic which includes extensions to mimic the legacy Gnome 2 session. I cannot speak for others distribution as I haven't used them.

[leech]

It seems an issue specific to the distribution i.e. Ubuntu in this case because the same desktop environment Gnome Shell 3.3 running on Fedora 31 powered HP Envy x360 Ryzen 2500u runs smooth without requiring 5 GHz as a minimum. Even the previous Gnome Shell 3.32 on Fedora 30 runs smoothly.

Edit: Test the same hardware with a livemedia Fedora Workstation 30 or 31 and see if you encounter the same problem.

I'm guessing not so much the distribution, but probably due to the extra extensions that Ubuntu install on their Gnome release by default. Whereas I think Fedora and Debian and others just have a straight setup of Gnome-shell.

[finalzone]

I'm talking about a test I've done a while ago with Ubuntu running on bare metal, so I'm pretty sure it was accelerated. It dropped frames even with no software running, so I'd say you probably need that 5 GHz CPU to have a chance of seeing animations play the way they were intended to be, and not look like a skippy mess.

It seems an issue specific to the distribution i.e. Ubuntu in this case because the same desktop environment Gnome Shell 3.3 running on Fedora 31 powered HP Envy x360 Ryzen 2500u runs smooth without requiring 5 GHz as a minimum. Even the previous Gnome Shell 3.32 on Fedora 30 runs smoothly.

Edit: Test the same hardware with a livemedia Fedora Workstation 30 or 31 and see if you encounter the same problem.

[GrayShade]

Guest You didn’t test 3.34/35 and you clearly didn’t read vanvugt’s blog.

Of course, Guest is wrong since even Daniel's blog says that Gnome has a lot of issues that make it drop frames regardless of how fast your hardware is. Not even 5 GHz will save you from those.

I'm using Gnome 3.34. It's much better than a couple of years ago, mostly thanks to Daniel's work. But then again, if your WM burns 80% CPU just because you're moving a window, calls fsync() on the main thread, or can't draw the mouse cursor when other programs use CPU, people will complain.

The compositor is basically a (soft) real-time app, and should be written as such. It should avoid GC pauses and disk access on its main thread. It shouldn't lag for a couple of seconds when I move the mouse cursor over the clock area. And, of course, it shouldn't crash and lose my session because my "XBill" extension crashed.

Which distribution was used to run Gnome Shell? Switch to another major one and see the same specification will have no problem running it. Another possibility is your test was done through virtualization using LLVMpipe as a fallback. The two laptops I mentioned earlier i.e. 2007 Sony VIAO and 2005 LG Tabet PC much older than your I5-8400 powered device have no problem on Fedora Workstation.
I am writing from the soon to be launched Fedora 31Workstation based running on HP Envy x360 Ryzen 2500u at 1.3 GHz frequency according to lscpu command. Therefore the claim that Gnome Shell needs at least 5GHz cpu is invalid.

I'm talking about a test I've done a while ago with Ubuntu running on bare metal, so I'm pretty sure it was accelerated. It dropped frames even with no software running, so I'd say you probably need that 5 GHz CPU to have a chance of seeing animations play the way they were intended to be, and not look like a skippy mess.

[Britoid]

Vanvugt repeated what other GNOME devs have said for years. Javascript is not a problem. Threading is not a solution.

I'd argue KMS and input threading should be something to aim for in the future because it helps prevent the compositor from delaying input and the screen updating. But it would of just put a rubber band on the performance problems that have or are being fixed.

[Britoid]

That depends entirely on how you see Ubuntu:

• Modern desktop OS
• Server OS
• IoT and embedded OS

I'd argue that most people on Phoronix would fall into the first category. The latter two have much better and faster options than Ubuntu nowadays so I guess it's the right move by Canonical to optimize for fast machines.


Daniel's work is a fucking godsend to Mutter and honestly the smug greybeards at Gnome just don't deserve Canonical's improvements.

Oh wow, someone who's paid full time to work on GNOME Shell performance patches is able to create them at a faster rate compared to people who volunteer and have to maintain the entire shell, not just parts responsible for rendering.

GNOME Shell only has a couple of full-time maintainers.