GNOME Bugzilla – Bug 787001
clutter-gtk apps like totem and gnome-maps are spending 50% of their CPU time redrawing GTK widgets
Last modified: 2021-06-10 11:18:01 UTC
Created attachment 358746 [details] Totem CPU profile from Google Profiler In the attached profile (from Google Profiler) you can see totem is spending 50% of its CPU time in gtk_widget_render and cairo_fill etc. This is while playing a 60FPS video while maximized in Gnome Shell Wayland. By reverting commit db93c9d9ce3, or simply removing its call to gtk_widget_queue_draw, the problem is solved. Totem and gnome-maps' CPU usage is halved. But the problem then is that the skipped frames problem mentioned in commit db93c9d9ce3 returns (especially visible in gnome-maps).
I'm definitely *not* going to revert that commit, as it not only has been in place since 2009, but it's also technically and semantically correct. The high CPU usage happens inside the GStreamer pipeline, in the vaapi driver, which makes me think it's falling back to some non hardware accelerated path, and you're probably better off without gstreamer-vaapi. On top of that, there's a lot of color buffer conversion happening around the GL pipeline, which means it's not doing things in the right texture format — again, something in between GL and the VA API driver. This, at least, accounts for the high CPU usage of a video app like Totem. I have no idea what Maps does, though as far as I know they switched to drawing tiles using Cairo, which means rendering is done client-side and then blending is done GPU side, after uploading to GL textures. That involves copying buffers around, which likely saturates your memory bandwidth and chokes the rest of the system.
Please see the profile in the description. It shows the high CPU is in gtk/gdk/cairo/pixman (graph on the left), not related to video decoding which is only using about 35% (graph on the right). The two graphs are the same process but disconnected because this is a stochastic profiler that didn't find strong connections between those two threads. GTK is using more CPU (half of a Xeon core) to render its widgets (mostly fill_boxes and pixman_fill) than the video decoding uses :) The problem is the signal connection to "queue-redraw" introduced in commit db93c9d9ce3. It is causing the app's widgets to get redrawn at the same 60Hz as the video itself. I agree and can see in gnome-maps that commit db93c9d9ce3 does improve smoothness. So I'm looking for a way to solve both problems. Not simply removing commit db93c9d9ce3...
-"half of a Xeon core" +"half of totem's CPU usage"
Created attachment 360460 [details] [review] 0001-Avoid-stage-redraws-triggering-window-redraws.patch Here's a patch that works without reverting the offending commit. Although I would be just as happy to revert the commit still. This does impact smoothness very slightly but only in one app on one machine AFAIK (which I won't have access to for another week). The additional smoothness fixes required are coming separately: * GTK: bug 787665 * Clutter (GDK backend) does not get GDK-Wayland frame callbacks after this patch and so GdkFrameClock doesn't get quite the right frame interval for displays != 60Hz. But most people actually won't notice those issues. They're not blocking this one.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of clutter-gtk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/clutter-gtk/-/issues/ Thank you for your understanding and your help.