When I press [Super] to show the Activities Overview, it will take many seconds to actually show.
This doesn’t happen when I first start my computer. Not sure if it is a problem of having open windows that have complicated rendering, or a problem of running many applications that altogether use a lot of memory. In all cases, there is a smooth operation in general, but suffer a big lag when showing the Activities Overview.
Are Gnome devs aware of the issue? Are many people experiencing the same?
Yes, swap is in use, as I typically work with many browser tabs open and IDEs.
However, my system is not overloaded; no application that I use is lagging. From my point of view, the Activities Overview definitely shouldn’t lag, it being a high priority for responsiveness.
If this happens with all extensions disabled (you may need to logout and log back in to make sure), you want to install all -debuginfo packages for gnome-shell, mutter, etc. and profile with Sysprof to figure out what’s going on, which would be helpful in a bug report, because it’s been butter-smooth for me here since 46-47 and particularly 48. Check out this guide about Sysprof…
Hi. I have captured one of those delays in Sysprof. I have no experience in Linux system calls, but the names seem to indicate a delay in the graphics driver fetching virtual memory pages. My guess is that those contain the current snapshots of my open windows.
Based on my findings, I was using the i915 driver, and gave a try forcing to use the xe driver. It is running much better. When using a lot of virtual memory, the transition to the Activities Overview is not smooth, but much faster, subsecond.
I find it surprising though that no Gnome developer has manifested interest in this issue, the Activities Overview being one of the main features of Gnome. It seems to depend a lot on the efficiency of the driver quickly fetching window snapshots, instead of loading those lazily, or first load lower resolution snapshots, which is what I would expect.
People contributing to GNOME are not an interchangeable quantity: the people working on GNOME Shell already have a ton of issues to look through already, on top of having to implement new features.
You are clearly experiencing something that is particular to your set up; it is up to you to investigate it, and then open an issue on GitLab with your findings.
There isn’t anything particular about my set up. I’d say rather the contrary. Stock Dell XPS 13, Arch Linux with vanilla Gnome installed. Default drivers being used, until I tried the alternative “xe” driver which did improve my situation. I also tried another laptop of the same model, running latest Fedora, with the same issue.
Regarding the way to report issues, I haven’t found indications on how to do it. In every case, is there an expectation that final Gnome users create a Gitlab account, search for the project in question and open an issue there?
I’m not expecting anybody jump to solve the issue I’m experiencing straight away. But I had expected some interest in assessing the issue, given its importance and chances that it is actually commonly found. Not sure if that is the role of developers or some product manager.
Since doing an Arch upgrade that has updated to Linux 6.15, I am now experiencing much better behavior (the Activities Overview now shows up quite immediately), using the default i915 graphics driver.
Regarding Issue Reporting for Gnome users, I find it an unreasonable barrier to have to find instructions for that in some subsection inside the Project Handbook, then have to find the corresponding Gitlab project and write an issue there. In my opinion, there should be a clear way from the homepage to report an issue.
GNOME is not a single application: it is composed of various projects. That’s why the documentation for project-wide behaviours is available in the handbook, as opposed to shoving it into the main website.
Additonally, reporting an issue on the GNOME GitLab instance is for people that already know where the issue lies, or, at the very least, that have a reasonable idea about it; issues can be moved around by maintainers.
For the uninitiated user, you should always start from your Linux distribution’s issue tracker.
