Skip to content

Opening the appearance panel with lots of wallpapers is slow (part 2)

In #2448 (closed), @velsinki valiantly tried to improve performance. However, I am still seeing slow performance for the wallpapers/backgrounds panel on my desktop computer with version 46.3.

Relevant information

  • GNOME Settings version: 46.3
  • Operating system (distribution): Fedora 40

Steps to reproduce:

  1. Use a hard disk drive (or anything that can help exacerbate the problem)
  2. Have about 100 wallpapers added to the GNOME Settings backgrounds panel
  3. Cold boot, or drop your kernel's disk caches with sync && sync && su -c "echo 3 > /proc/sys/vm/drop_caches" (this is safe to do at any time; it will give you a "not entirely cold, but lukewarm" cache, in my experience)
  4. Launch gnome-control-center background (or GSK_RENDERER=gl gnome-control-center background)

In my case, it takes 10 to 20 seconds to show the grid of thumbnails and for the app to become responsive again.

Pre-diagnostics

A sysprof capture (download) shows that a lot of time is spent loading images, and it feels like an I/O bound thing:

Flamegraph of most expensive function calls (with the default GSK renderer, ngl):

GNOME_Control_Center_46.3_wallpapers_panel_HDD_startup_performance_Sysprof_capture_-_flamegraph

Disk I/O usage CPU usage
GNOME_Control_Center_46.3_wallpapers_panel_HDD_startup_performance_Sysprof_capture_-_disk_IO_usage GNOME_Control_Center_46.3_wallpapers_panel_HDD_startup_performance_Sysprof_capture_-_CPU_usage

Marks over time:

GNOME_Control_Center_46.3_wallpapers_panel_HDD_startup_performance_Sysprof_capture_-_marks

I do not consider this to be the same issue as @automerisnaranja's #2879 (closed), because:

  • It's not noticeably "Slower than 45", it's "just as slow as 45" for me;
  • It happens even with GSK_RENDERER=gl gnome-control-center background;
  • I'm suspecting this is G-C-C trying to load full images (and resize them on the fly) instead of generating (and later reusing) them in the XDG thumbnails cache, and if so, this is always going to be extremely slow with large numbers of images, especially on HDDs;
  • On a warm cache (i.e. second launch shortly after), it opens reasonably quickly, so the problem is more about trying to read huge files all at once rather than displaying appropriately-sized thumbnail pixbufs.

If my hunch is correct, and g-c-c doesn't already generate (or copy!) and store standard Freedesktop thumbnails in the corresponding cache location, and only stores copies of the full-resolution wallpaper images (somewhat technically related: #2950), then g-c-c should do the thumbnails caching thing.