Slow Appearance loading in GNOME control center
Closed this issue · 6 comments
Affected version
webp-pixbuf-loader 0.2.2-1
gnome-control-center 43.4.1-3
gnome-shell 1:43.3-2
Bug summary
Gnome settings Appearance windows with background changing:
Some of wallpapers taking a lot of time to change, some of them working fast. Default one is taking 4-7 seconds to be set up, wallpaper itself and icon 'V' of current wallpaper appearing with delay.
During discussion here https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6545#note_1707528 it turned out this behavior is related to webp-pixbuf-loader. Downgrading to webp-pixbuf-loader 0.2.2-1 -> 0.0.7-1 makes settings responsive again.
Possibly affects https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5086
Steps to reproduce
- Open gnome-settings
- go to Appearance part
- change between built-in wallpapers
- some of them are slow to apply
What happened
Time delay during wallpaper changing
What did you expect to happen
Wallpaper changes as expected
Using something like the following is quite a speedup, because gdk_pixbuf_get_file_info() is called from a lot of places in gnome-desktop and gnome-control-center and that always results in an unnecessary stop_load() -> WebPDecode(). Checking for a size of 0 is something that the TIFF loader does to detect gdk_pixbuf_get_file_info(), but I'm not sure if there is a better way of doing that.
diff --git a/io-webp.c b/io-webp.c
index 86a04d4..db56441 100644
--- a/io-webp.c
+++ b/io-webp.c
@@ -149,6 +149,12 @@ stop_load (gpointer data, GError **error)
height = scaled_h;
}
+ if (scaled_w == 0 || scaled_h == 0)
+ {
+ ret = TRUE;
+ goto out;
+ }
+
GdkPixbuf *pixbuf = gdk_pixbuf_new (GDK_COLORSPACE_RGB,
context->has_alpha, 8, width, height);
if (icc_data)
@@ -187,6 +193,7 @@ stop_load (gpointer data, GError **error)
g_object_unref (pixbuf);
}
+out:
if (context->buffer)
g_byte_array_free (context->buffer, TRUE);
g_free (context);I am already working on a fix for this. Doing this in stop_load means we need to copy the entire encoded image in memory first.
I am branching the non animation codepath, I will add a check for this afterwards.
Thanks for looking into this.
Please test with the latest release, 0.2.4, things should be better.
I tried to use the incremental decoder again, but it is broken for large files.
I have added an automated test for one of the background images that gets run on the CI now.
With this the load time for the background images is comparable to the default F38 background. That background is a 4032x3024 PNG which is comparable in size to the GNOME background images (4096x4096). I also tried switching back and forth between this and 0.0.7 and I don't notice any performance difference, so I think the performance regression can be considered fixed.
Awesome! Thanks!