After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769097 - Totem with GTK+ 3.21.4 has the top controls bar constantly flickering on and off over the video frame
Totem with GTK+ 3.21.4 has the top controls bar constantly flickering on and ...
Status: RESOLVED FIXED
Product: clutter-gtk
Classification: Platform
Component: general
1.8.x
Other Linux
: Normal normal
: ---
Assigned To: clutter-gtk maintainer(s)
clutter-gtk maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-07-22 20:06 UTC by Daniel Boles
Modified: 2016-09-13 21:10 UTC
See Also:
GNOME target: ---
GNOME version: 3.19/3.20


Attachments
Screenshot of totem showing the flickering extra toolbar. (282.89 KB, image/png)
2016-08-14 21:12 UTC, Hussam Al-Tayeb
  Details
embed: remove non double buffer setting (1.59 KB, patch)
2016-08-29 20:17 UTC, Lionel Landwerlin
committed Details | Review

Description Daniel Boles 2016-07-22 20:06:29 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
Comment 1 Daniel Boles 2016-07-22 20:14:21 UTC
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.
Comment 2 Daniel Boles 2016-07-22 20:18:37 UTC
Here's the GTK+ commit that added that warning:

https://mail.gnome.org/archives/commits-list/2016-May/msg06553.html
Comment 3 Hussam Al-Tayeb 2016-08-14 21:02:48 UTC
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.
Comment 4 Hussam Al-Tayeb 2016-08-14 21:12:23 UTC
Created attachment 333299 [details]
Screenshot of totem showing the flickering extra toolbar.

Screenshot of totem showing the flickering extra toolbar.
Comment 5 Sebastian Keller 2016-08-21 05:01:15 UTC
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.
Comment 6 Sebastian Keller 2016-08-21 05:03:31 UTC
Wrong link, here's the right one:
https://git.gnome.org/browse/gtk+/commit/?id=40ee61a686826ac8e937af720bc152895b10392b
Comment 7 Emmanuele Bassi (:ebassi) 2016-08-23 16:27:08 UTC
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.
Comment 8 Hussam Al-Tayeb 2016-08-29 13:12:25 UTC
Removing the call does fix totem for me. But I haven't tested yet if it causes regressions elsewhere.
Comment 9 Lionel Landwerlin 2016-08-29 20:17:21 UTC
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.
Comment 10 Emmanuele Bassi (:ebassi) 2016-08-30 08:39:00 UTC
Review of attachment 334403 [details] [review]:

Thanks, LGTM.
Comment 11 Lionel Landwerlin 2016-08-30 10:32:00 UTC
Review of attachment 334403 [details] [review]:

Pushed to master.
Comment 12 Bastien Nocera 2016-08-30 10:44:07 UTC
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
Comment 13 Hussam Al-Tayeb 2016-08-30 11:59:57 UTC
(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.
Comment 14 Lionel Landwerlin 2016-08-30 12:01:07 UTC
I tested this on both Wayland and X11 :)
Comment 15 Daniel Boles 2016-09-13 21:10:12 UTC
(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.