GNOME Bugzilla – Bug 769097
Totem with GTK+ 3.21.4 has the top controls bar constantly flickering on and off over the video frame
Last modified: 2016-09-13 21:10:12 UTC
The title says it all, really. I run Debian unstable but recently force-upgraded its GTK+ 3.20.6 to experimental's 3.21.4 to get some recent fixes. So there might be a dependency unmet somewhere that's doing this. But clarification would be appreciated anyway. I selected the resolution that involved also upgrading GLib, gail, girl, Adwaita icons, etc. And I've now noticed that Totem doesn't seem to like the new GTK+. Confirmed by down/upgrading and checking results. GTK+ 3.20.6 and associated packages work fine; upgrading to 3.21.4 causes the flickering. Perhaps this is 'just one of these things' when going for experimental packages or mixing/matching, but I'd appreciate a general idea anyway. If it isn't, then I hope this can be useful as an early notification. Running Intel HD Graphics 4000 with a discrete Nvidia GT650M on board also. FWIW though, GNOME only acknowledges the former of those two. Any other specific info wanted, let me know. I didn't try taking a screencast due to how fast the flickering is... but if you really want one, I can try. Cheers
Running with GTK_DEBUG=interactive probably supports the idea that I'm just doing something I shouldn't ;-) as there seem to be API usage incompatibilities. The top bar flickering seems to be due to it being constantly shown/hidden, which are accompanied by continuous events such as (but not necessarily limited to) the following: (totem:12967): Gtk-WARNING **: GtkBox 0x55c9fdb2daf0 is drawn without a current allocation. This should not happen. (totem:12967): Gtk-WARNING **: GtkImage 0x55c9fdb879e0 is drawn without a current allocation. This should not happen. (totem:12967): Gtk-WARNING **: GtkScale 0x55c9fce98d30 is drawn without a current allocation. This should not happen. (totem:12967): Gtk-WARNING **: GtkToolItem 0x7fcfc4014e90 is drawn without a current allocation. This should not happen. (totem:12967): Gtk-WARNING **: GtkBox 0x7fcfc4012ad0 is drawn without a current allocation. This should not happen. (totem:12967): Gtk-WARNING **: GtkMenuButton 0x55c9fce98f40 is drawn without a current allocation. This should not happen. (totem:12967): Gtk-WARNING **: GtkImage 0x55c9fd7fbb50 is drawn without a current allocation. This should not happen. (totem:12967): Gtk-WARNING **: GtkClutterOffscreen 0x7fcfc4012120 is drawn without a current allocation. This should not happen.
Here's the GTK+ commit that added that warning: https://mail.gnome.org/archives/commits-list/2016-May/msg06553.html
I can see two control bars. The working one at the bottom and a flickering on at the top. The one at the top was not in gtk+ 3.20. It just sits there flickering.
Created attachment 333299 [details] Screenshot of totem showing the flickering extra toolbar. Screenshot of totem showing the flickering extra toolbar.
I've bisected this down to this gtk+ commit: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?id=40ee61a686826ac8e937af720bc152895b10392b Because clutter-gtk disables double buffering as well, it takes the same fallback code path as firefox. Enabling double buffering in clutter-gtk causes it to take the code path it was taking before that commit and stops the flickering. That's probably not the right way to fix this, though.
Wrong link, here's the right one: https://git.gnome.org/browse/gtk+/commit/?id=40ee61a686826ac8e937af720bc152895b10392b
The reason why GtkClutterEmbed used gtk_widget_set_double_buffered(FALSE) was because of flickering with GTK+ 2.0, back when it was written. GDK's drawing model is now fairly different from the past, and set_double_buffered() is deprecated API. If by removing the set_double_buffered() call we don't regress, I'm all for dropping it. The difference between the escape hatch introduced for Firefox is that Firefox is drawing on a top-level GdkWindow, with its own double buffering code; this is different than what GtkClutterEmbed has always done — it creates a child GdkWindow backed by a native surface. If we want to be conservative, we can add a version check like: #if !GTK_CHECK_VERSION (3, 21, 0) gtk_widget_set_double_buffered (GTK_WIDGET (self), FALSE); #endif inside GtkClutterEmbed:gtk_clutter_embed_init(), but I'm perfectly comfortable with making clutter-gtk depend on GTK+ ≥ 3.21.0 in the configure.ac.
Removing the call does fix totem for me. But I haven't tested yet if it causes regressions elsewhere.
Created attachment 334403 [details] [review] embed: remove non double buffer setting This started causing problems with Gtk+ 3.21. As the documentation explains, disabling double buffering might trigger rendering issues.
Review of attachment 334403 [details] [review]: Thanks, LGTM.
Review of attachment 334403 [details] [review]: Pushed to master.
Reassigning to clutter-gtk to make it clear where the patch landed. I bumped the version requirement for what will become totem 3.20: commit a81bb54f19540d666065c6789b0c541e4841311d Author: Bastien Nocera <hadess@hadess.net> Date: Tue Aug 30 12:42:53 2016 +0200 build: Bump clutter-gtk version req To get the fix for flickering popup on Wayland. See https://bugzilla.gnome.org/show_bug.cgi?id=769097
(In reply to Bastien Nocera from comment #12) > To get the fix for flickering popup on Wayland. > Just for the record, this was an issue on Xorg as well.
I tested this on both Wayland and X11 :)
(In reply to Hussam Al-Tayeb from comment #13) > (In reply to Bastien Nocera from comment #12) > > > To get the fix for flickering popup on Wayland. > > > > Just for the record, this was an issue on Xorg as well. Yeah, I probably should've said, I use X.org and originally reported this on that basis. Anyway, fixed now, woo! Thanks all.