Thank you so much for this. I understood 0.4% of it but it is super interesting and please keep posting stuff like this. It is very enlightening.
I’m using ubuntu on wayland for a while (Unity and Gnome since Unity abandon). But with ubuntu 19.10 upgrade, Gnome was so slow and laggy that I had thought to downgrade or a new laptop. I switched back to Xorg and now everything is as smoth as usual.
I have an intel card, don’t know if it can help.
Nice read. Nice work. I will definitely check out 19.10 soon to see it for myself.
Sorry for the delay; I just got back from vacation.
I would like to investigate your performance issue in more detail, but not here… Please run this command on the affected machine to open a new bug:
Finally I’ve had also this problem with xorg. It seems that it’s related to a kernel problem:
It’s a shame that your work is masked by other problem. Thanks for the nice work (and article).
@vanvugt I would like to ask for some clarification about your answer to my comment in Gnome Gitlab about frequency scaling. Since it was becoming a bit OT there and it’s a question of a more general nature about the way to tackle the animation that is most obviously lacking in Gnome Shell (the overview animation, of course), I opted to ask you here. What surprised me in your answer is that you say that good frequency scaling has to been seen only as a workaround here because resolving the underlying issues will make it less relevant or pressing. Now, as I understand it, this animation is processing intensive and, by its very nature, demands a processing burst when the CPU/GPU less expects it, so no “moving average” heuristic will do it and you need either to lock frequency too high and burn your battery out or scale frequency too fast. How can you work around this issue? Do you mean to implement the altogether different approach of snapshotting as described here?
I know with performance issues distinguishing between a fix and a workaround can seem arbitrary. In this particular case I have a plan which seems to work in preliminary testing. And it works more reliably, and faster/smoother, without forcing frequency scaling harder. The animations are not as you say “processing intensive and, by its very nature, demands a processing burst”. They’re just being slowed down by a bug for which higher frequencies are a workaround, but it’s also possible to fix. That set of fixes is my current focus this month.
I agree more responsive frequency scaling would improve the user experience, as I have experienced myself when I first proposed it. Although that got reverted because it exposed bugs in the Wayland backend so will need to be reattempted in future. And I made another different attempt at scaling over the new year. So I haven’t given up on scaling, only deprioritised it for the moment.
What that means? Is or is not gjs? The profile don’t lie i think.
This is Very Interesting want to try and figure out exactly what was causing my slow load times in ubuntu 19 which i am sure is some header but the app load lag seems to have gone away with Ubuntu 20 which i am very pleased by default (if which may take a while figure to out my trouble solving issue will post) Thanks
gjs#302 looks like a simple issue to fix, in theory. And it might affect a lot of the shell. I was just waiting overnight to see if the GJS developers had advice on the issue before trying to prototype fixes myself.
Agree with this post i feel as if the Nvidia tab is severly lacking an options for Linux based systems in comparison to Windows 10( my biggest peeve right now that the Vsync overall on feature available to windows 10( i have to adjust Xonf.d to make this happen but it keeps crashing) and i was considering multiple monitor setups myself but i have to fix main issues first )(Edit: Running Dual Monitors form a laptob takes a huge amount of graphics power ( maybe a laptob with dual rx580 with dual hdmi connections to two monitors )in my past experiences attempting even running dual monitors on a single 660 gtx can be quite heavy technically you would need a graphics per monitor to get full performance in my opinion based) ( i think somewhere around old laptobs with m700seriesish ive tried this and had nothing but problems your main display goes to laptob LED then your also putting out two more monitors its jsut too much for a laptop to handle maybe a quadro can but ive run recent graphic benchmarks against quadros and seem them very minimal performance for what your attempting)9Edit: Considering what you said also about same computer but it works fine what are doing video editing gaming whats causing this to happen specifically(curiosity) are the dual monitors running in 2k each in comparison to other computers resolution jsut alot of information that is making have to t ake a break and think bout all this :)?
What’s the best way for those of us on focal to help you with testing? Is there a 3.36.x branch packaged for ubuntu that we should be running? Apart from general feel is there data collection that can be done that’d inform the work?
Ive been doing, Ubuntu-bug , plus benchmark test with Phoronix Test-suite
Bryce, good questions. Unfortunately 3.35 only exists in git right now. It’s too fluid and I’m in too much of a hurry to try packaging it early. Plus there are dependencies I don’t yet know how to handle and patch away for my own development.
To help in general I would just like to hear what peoples’ top priorities are. After the overview animations performance fixes land. Since I said I would prioritise “fast on fast machines” I think the next areas of focus would be these (which still stutter on my i7-7700 desktop):
- Workspace switching
- App grid scrolling
- Wayland multi-monitors
We can’t realistically expect low-end machines to run Gnome well until fast machines can…
Ok thanks. I’m on a i7-8700 CPU @ 3.20GHz so fast on fast as a priority certainly WFM. I’m wondering if some of my performance troubles may be related to being on a radeon card with 6 monitors, so multi-monitor optimizations would be my #2; in perusing the upstream git tree it looks like there’s been some work on multihead performance so I will look forward to any testing help I can give on 3.36 when you’re ready for testers. Thanks!
Note that I was referring to Wayland multi-monitors. Not Xorg multi-monitors. The Wayland code path has its own unique reason for being slow. After that, multi-monitor performance issues should be the same between Xorg and Wayland.
Also note the default Xorg modesetting driver will tear with multiple monitors. That’s actually a harder problem, so it’s one reason to try and get the Wayland option polished.
Wayland multi monitors definitely my highest priority. I can’t really use gnome as it stands today for that reason.
Same here, multi-monitor is highest on the list. Followed by app grid scrolling.
+1 for Wayland multi-monitor awesomeness!
A problem with focusing on wayland is multi-monitor -> probably multi-dpi -> probably fractional scaling -> probably chromium based app (electron) -> blurriness. But fixing xwayland fractional scaling might be harder and take longer than waiting for igalia’s changes to be merged into chromium (I believe they were moved to beta recently) and the entire electron stack to follow suit.