Another Intel 4K + GNOME Optimization Yields 5% Faster Render Times, 10% Lower Power Use

[phoronix]

Phoronix: Another Intel 4K + GNOME Optimization Yields 5% Faster Render Times, 10% Lower Power Use

Daniel van Vugt of Canonical who has been responsible for many GNOME performance optimizations in recent years has another tantalizing improvement under review...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-GNOME-4K-Avoid-Multiply

[brent]

BUT WAIT, there's more!

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1329

[down1]

Next week he'll discover every 3rd window is being painted 100 times.

[brent]

Next week he'll discover every 3rd window is being painted 100 times.

That's sarcasm for sure, but I do wonder how GNOME developers managed to make everything so slow and inefficient and why it took so long to find out. Maybe it's a good idea to browse through the shaders generated for mutter and look for more.

[down1]

brent Most devs prefer to avoid premature optimizations. Stuff gets fixed when profiling proves it to be significant. So the new thing is that profiling now targets higher pixel count systems like 4k screens and 2x 4k screens.

This doesn't apply to situations where window cullng is supposed to be implemented but is not in fact running.

[andyprough]

That's sarcasm for sure, but I do wonder how GNOME developers managed to make everything so slow and inefficient and why it took so long to find out. Maybe it's a good idea to browse through the shaders generated for mutter and look for more.

If it's like a lot of other GNU/Linux projects, many of the devs are using MacOS for their own machines instead of eating their own cooking. One big reason I prefer MX is the devs actually use it and talk to you about it in the forums every day.

[brent]

brent Most devs prefer to avoid premature optimizations. Stuff gets fixed when profiling proves it to be significant. So the new thing is that profiling now targets higher pixel count systems like 4k screens and 2x 4k screens.

"Premature", sure, LOL. GNOME 3.0 was released around 10 years ago. As far as I can tell, there simply was no serious profiling and analysis being done until some ~3 years ago - and performance issues were mostly ignored or downplayed by developers. This culture of ignorance w.r.t performance hurt GNOME a lot. I'm glad we're beyond that, though.

[down1]

brent Oh you were just here to happy troll a bit and didn’t knew how Daniel works. He keeps repeating the same speak on Gitlab. Never guess, always profile. Never do premature optimization, work on what matters.

If you have window culling code implemented and it isn't running then it should be removed or the bug fixed. It isn't premature optimization if you are fixing something that is suppose to happen.

[240Hz]

The question is, what are the rest of GNOME devs doing, besides outreachy and other bullshit? Without Daniel there would be no Gnome Shell or Mutter

[AnAccount]

The question is, what are the rest of GNOME devs doing, besides outreachy and other bullshit? Without Daniel there would be no Gnome Shell or Mutter

Are you really this stupid, or are you just trolling? You know that the commit history is public, so you could actually check... but I assume you might not have the skills to actually do that.