GNOME Bugzilla – Bug 782839
gnome-control-center buttons, lots of draw calls
Last modified: 2018-01-04 15:30:30 UTC
The gnome-control-center background panel can use a lot of CPU and become slow. According to this downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1392874 it is a gtk bug. The problem seems to come from the draw function of a GtkDrawingArea inside a GtkButton. The function is cpu intensive (it generates a thumbnail), and is called every time the window or the button is animated (mouse hovering for example). It also is seems to be called during the gnome-shell overview animation. It happens with Wayland and Xorg.
it is not a gtk bug if draw handlers of applications do expensive things.
I'd actually move this bug to gnome-control-center, even though I'm pretty sure that the background panel is getting a re-design for the new shell. Currently, the panel gets a frame of the background (in case it's animated) as a GdkPixbuf, creates a Cairo context on a separate Cairo surface, renders it, then takes the screenshot of the screen (minus the root window), scales it on the CPU, and renders the screenshot on top of the new background. In theory, the panel should not create additional Cairo contexts, but it should use the Cairo context provided by the GtkWidget during the draw() call; the API for getting the background should return a Cairo surface instead of a GdkPixbuf; the panel should cache the background frame and the composited preview while it's open; instead of using signals, the panel should subclass GtkDrawingArea and override the draw() implementation; the draw() implementation should also *only* set the preview as the rendering source, to avoid constantly doing rendering operations while the button changes state but not content.
(In reply to Emmanuele Bassi (:ebassi) from comment #2) > I'd actually move this bug to gnome-control-center, even though I'm pretty > sure that the background panel is getting a re-design for the new shell. Thanks. I think it is now a dupe of : https://bugzilla.gnome.org/show_bug.cgi?id=765887 > Currently, the panel gets a frame of the background (in case it's animated) > as a GdkPixbuf, creates a Cairo context on a separate Cairo surface, renders > it, then takes the screenshot of the screen (minus the root window), scales > it on the CPU, and renders the screenshot on top of the new background. > > In theory, the panel should not create additional Cairo contexts, but it > should use the Cairo context provided by the GtkWidget during the draw() > call; the API for getting the background should return a Cairo surface > instead of a GdkPixbuf; the panel should cache the background frame and the > composited preview while it's open; instead of using signals, the panel > should subclass GtkDrawingArea and override the draw() implementation; the > draw() implementation should also *only* set the preview as the rendering > source, to avoid constantly doing rendering operations while the button > changes state but not content. Thank you for your explanation. I hadn't look that closely, I just noticed that the situation is way better by just calling cc_background_item_get_frame_thumbnail with force_size set to FALSE instead of TRUE (don't know how it handles animated backgrounds though, since it seems to use a cache). But if the panel is going to be redesigned, I guess it doesn't matter.
Patch created and attached to https://bugzilla.gnome.org/show_bug.cgi?id=765887
*** This bug has been marked as a duplicate of bug 765887 ***