GNOME Bugzilla – Bug 748498
Black background appears briefly before window gets drawn
Last modified: 2018-05-02 16:34:08 UTC
Created attachment 302400 [details] application startup video When an application is started, a black background is drawn first, before the application's window content appears. This is only happening when I'm not using a compositor. If compositing is turned on, all the windows get drawn nicely (without the black background appearing). I'm using GNOME applications outside of GNOME; I tested this with Openbox/Compton and with Xfce4's window manager/compositor and they both had the issue. It's also only happening with GTK3+ applications, GTK2 and applications using other toolkits get drawn without the black background. I attached a short video clip which demonstrates it.
Starting from gtk 3.18 on Xfce, this behavior is more evident than previous gtk versions. With or without a compositor, the black background is shown and is very ugly, especially on light themes. On gtk 3.16 I can use a compositor to solve the problem, but on 3.18 not.
same is happening here on Ubuntu with gtk 3.18 under unity
The black may be coming from the X11 server — GTK+ 3.x heavily relies on the frame clock driven by a compositor using the _NET_WM_SYNC_REQUEST protocol: https://mail.gnome.org/archives/wm-spec-list/2011-October/msg00006.html whereas GTK+ 2.x just drawn whenever the main loop was ready, thus reducing the potential for flickering. Admittedly, the video shows an extreme effect, so I'm not entirely sure the lack of frame synchronisation is wholly to blame, here.
Although I don't understand it yet, I bisected to see if there was a commit which made this effect more pronounced. It turned up 74f2d9448f24bbfdaf32ae6b328ed3e126700afe.
Could this have "Importance" increased? It's very disruptive. I see there is Ubuntu distributed patch that basically makes window transparent on creation, though I'm not certain it is correct solution. As it is, this bug presents itself regardless of compositor running or not. I'm testing on GTK 3.20.2 with default (Adwaita) theme. For some reason it is mainly affecting windows that are dialogs. E.g., I'm testing with "spacefm" file manager and its "Preferences" dialog.
If this is very disruptive on ubuntu, then it should be a priority for people supporting that os. And no, making all windows, transparent is not the right fix.
I'm testing on ArchLinux (should have said that) and not Ubuntu. While searching for remedy I've found Ubuntu bug report leading me here. GTK 3.20.3 vanilla (https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gtk3) Intel HD Graphics 4000 Linux hostname 4.5.0-1-ARCH #1 SMP PREEMPT Tue Mar 15 09:41:03 CET 2016 x86_64 GNU/Linux X.Org X Server 1.18.3 Release Date: 2016-04-04 Section "Device" Identifier "card0" Driver "intel" BusID "pci:0:2:0" Option "DRI" "3" Option "TearFree" "on" EndSection What I've tried with no success: * with/without compositor (compton) * with/without intel's TearFree * using 'modesetting' instead of 'intel'
Same issue on Fedora (24, 25) in a GNOME/Wayland session with several Gtk+ applications, including Firefox. Firefox is running under XWayland, so it looks like comment #3 still applies. This does not depend on a specific version of Gtk+, gnome-shell, firefox or XWayland, but has been present for at least a year. (In reply to Emmanuele Bassi (:ebassi) from comment #3) > Admittedly, the video shows an extreme effect, so I'm not entirely sure the > lack of frame synchronisation is wholly to blame, here. I'm seeing this extreme effect _every_ time I open a firefox window, which might be a separate bug: https://bugzilla.redhat.com/show_bug.cgi?id=1444663
This issue also happens during resizing, I've seen this for several applications running with on XWayland, e.g. with evolution or eclipse IDE. It seems like this only affects applications which are relatively slow to repaint since I cannot reproduce this with e.g. nautilus or gedit easily. With screen recording running, can reproduce this on any application running with GDK_BACKEND=x11. On a GNOME/Wayland session with pure wayland apps, this is harder to reproduce. I only managed to do so with applications which use internal compositing for drawing off-process content from e.g. WebKit2Gtk3, like Epiphany, Evolution or Yelp. So: Also happens on Wayland, but rarely and less bad.
(In reply to Matthias Clasen from comment #6) > If this is very disruptive on ubuntu, then it should be a priority for > people supporting that os. And no, making all windows, transparent is not > the right fix. The same issue is with Firefox/Fedora 26, both Wayland and X11 builds on Wayland session. The problem (AFAIK) is with CSD and delayed window composition - Firefox paints to child window where the parent one (with CSD shadows) may be already showed.
Firefox Gtk2 used gdk_window_set_back_pixmap(null) to disable GdkWindow background rendering. What's the best way to do that for Gtk 3.20+? Thanks!
Actually the bug is caused by delayed Firefox rendering at GdkWindow, when Firefox paints asynchronously (from compositor thread) to GdkWindow. Is there any way how to draw to GdkWindow asynchronously (so not at draw/expose event exclusively) and avoid the flickering?
Hm, I was wrong here - can be reproduced without any firefox rendering, just with default GdkWindow background. I'll try to create a Gtk only testcase for it.
Created attachment 356882 [details] testcase There's a simple testcase which shows this bug. This bug is exposed when main thread where Gtk events are processed is busy with different task, which is emulated by the loop here. Adjust the for cycle size for your box speed and then just hit alt+f10 to maximize the GtkWindow. The black square and window title/top bar is rendered immediately but the default GtkWindow background is rendered after it which causes flickering. Reproducible on both X11 and Wayland.
I see this bug on Arch when I open "About" dialog of apps running under xwayland like Firefox, K3b and Kdenlive. My video adapter is intel hd 4000.
Created attachment 358491 [details] Black background I have a similar problem on Fedora 26 as you can see. It's a new install and for now I only saw it in gnome control center. I'm on X11 with intel gpu (haswell - modesettings, glamor, dri3). Thanks !
It happen for me with when I use the modesetting driver instead of the intel one.
Guys, any update here? Users keep to report that as Firefox bug.
(In reply to Strangiato from comment #15) > I see this bug on Arch when I open "About" dialog of apps running under > xwayland like Firefox, K3b and Kdenlive. > My video adapter is intel hd 4000. It persists in gnome 3.26.1, Arch Linux.
*** Bug 757104 has been marked as a duplicate of this bug. ***
*** Bug 771708 has been marked as a duplicate of this bug. ***
re-adding what was removed in https://gitlab.gnome.org/GNOME/gtk/commit/74f2d9448f24bbfdaf32ae6b328ed3e126700afe fixes this on my system
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/550.