I can confirm Clement's report, but it happens with a compositor (compton) here, and also under Weston and Sway, both being Wayland compositors. Where this happens the most, even under Wayland compositors, is when in Gtk3 X11 mode.

Where it doesn't seem to happen if it's a Wayland compositor and a proper Gtk3 Wayland invocation of an application. However, such Gtk3 Wayland apps have the issue that things like file dialogs are scaled and all widgets are zoomed out or zoomed in instead of proper resizing of widgets according to the grid.

This regression is disruptive enough that I cannot use stable Firefox and have to resort to Firefox ESR for Gtk2.

Thanks Carsten for transferring my initial fedora bug report to the upstream gnome bug tracker. I have to admit, I avoided filing it here ... as can be seen now - the bug report has been filed a month ago and nobody even took a look to confirm it.

We welcome bug reports and we generally don't "confirm" bug reports. Someone might take a look when there's time+manpower, as usual in volunteer-driven free+open source software projects (whether that's Fedora or GNOME or something else).

Updated metadata to confirm it's the same in 3.22.2.

Something I forgot regarding the one scenario it doesn't seem to happen:

I would like to use a Wayland compositor for day to day work, but there's no capable replacement as of yet which would allow me (1) to use it instead of my X11 window manager that best fits my workflow and (2) has the least amount of Xwayland integration bugs. Even libweston(-desktop)'s Xwayland integration is buggy enough in the paper cuts department that I cannot yet use it. This is on top of Gtk3's file manager not fitting in the same display dimenasions where Gtk2's dialog does and forcing a zoom-out instead of scale-down.

All this means I cannot work around the Gtk3 drawing regression by switching to a Wayland compositor.

What it also means is that the drawing code path which exhibits the regression should be easier to identify given the scenarios I've described where it happens the least, not all, and the most.

Andre, I can build and try different Gtk3 revisions.

What's different under a X11 GNOME session vs gtk3 under a random X11 window manager that the developers do not see this behavior? Is it a missing setting somewhere that enables correct drawing?

It's also noticeably slower when you switch from a desktop with, say, an xterm to a desktop with a full-screen gtk3 window, than it is with gtk2. Need to test that with a Wayland compositor for comparison.

(Reverting Severity field value change. I cannot see anything critical here.)

Andre, how can we debug this to find the root cause? Again, I find it interesting that none of the gtk devs seem to suffer from this behavior, so what is it that X11 GNOME might be providing in the environment to gtk3 that might be circumventing the redraw regression?

This happens for me too. That was on a system when run with GNOME flashback session (using current Debian testing).

Mee to - on two Fedora 24 systems (one with intel, the other one with AMD GCN GPU).

carsten: the issue is not repoduceability, it is just nobody has tried it till now (as predicted).

> the issue is not repoduceability, it is just nobody has tried it till now (as predicted).

I don't understand. If the devs should be able to run into the same bug and since this started with 3.20, what exactly would they have to do other than open a random file or font selector dialog?

maybe they ran into this bug and didn't notice it or didn't feel the behaviour was too annoying or simply nobody felt responsible for fixing.
Until now, however, it seems likely nobody has given it a try.

As far as I know, basically everyone of the people developing GTK+ under X11 use a compositing window manager, and switching to a non-compositing one is a non trivial endeavour — you have to set up a completely different session, for instance. Additionally, X11 without compositing is pretty much broken with regards to consistency of rendering behaviour.

I definitely never saw something like what happens in the videos of the original report.

The only reason why the GTK2 and GTK3 cases seem to differ is that GTK2 filled the window with a generic grey background color, which would make other windows look bad anyway. Additionally, the rendering between GTK2 and GTK3 has been pretty drastically changed, so comparing GTK3 with GTK2 is pretty much the equivalent of comparing GTK3 with Qt3, or Tcl/Tk.

With a compositor running the toolkit can effectively ask the windowing system to present a window to the user only when it's fully redrawn; without it, it's completely best effort as to what reaches the user.

I don't want to downplay the issue: it would be nice to figure out what's happening; it could be that a code path was refactored out because it's not being exercised, or there's a bug in one of the composited/non-composited checks. Nevertheless, I think it's a fair assumption to say that the GTK+ developers consider the non-composited X11 case to not be a priority.

Thanks Emmanuele for replying. Let's try to identify the broken code
in order to come up with a fix.

Like I wrote initially, I always use a compositor because otherwise
there's extreme tearing since Sandybridge GPUs, and I've described the
ways the regression surfaces under different scenarios, including the
non-existence AFAICT under Wayland compositors, although the
zooming-out of widgets instead of scaling being an undesirable
rendering feature in the wayland backend. The generic modesetting ddx
is supposed to have zero tearing, but it tears as much as plain
xf86-video-intel, and there's no way to enable TearFree and combine it
with compton's hybrid vsync to stop all tearing.

Do I want to enable vsync? No, but it's the only way to use X11
without tearing because TearFree alone doesn't fix all instances, and
the generic modesetting driver tears in any config because it has no
logic to prevent tearing, as it exists under the assumption that DRI3
should fix it, which isn't the case in practice.

I understand how it's probably not a priority, but if the code path
which involves a random X11 WM plus compton for compositing or the WM
alone is not supported officially, then this needs to be communicated
clearly to all users. As it stands, it would be major news for that
restriction to be the case.

It's funny that pre-Sandybridge and pre-gtk3 things were simpler and
tearing wasn't the general issue it has become now. Kinda ironic, now
that Wayland is starting to get into a usable shape.

Can we get hints where to poke around in the code to figure out the regression or a commit range?

I understand this has no priority for the devs, but AFAIK gtk3 isn't exclusively supported when only being used under GNOME3. That means, unless GNOME3 is a requirement for proper functioning of gtk3 apps (say, beginning with 3.24), please help us out by providing debug hints so that non-devs could try to find the regression's cause.

If gtk3 requires to be run under GNOME3, please let us know. It'd be fine if that's the case, but an official statement would be needed to decide how to resolve the issue.

BTW, I've tried and failed to see the grey bg color you mentioned happens the same with gtk2 but goes unnoticed.

(In reply to carstenmattner from comment #16)
> Can we get hints where to poke around in the code to figure out the
> regression or a commit range?

You can try bisecting between a known good version using `git bisect`. Each release is tagged in Git, so you can do:

  git bisect good <the first gtk tag that works>

> I understand this has no priority for the devs, but AFAIK gtk3 isn't
> exclusively supported when only being used under GNOME3.

There are compositors that work outside of GNOME. Metacity has a compositor, for instance; KWin has a compositor.

(In reply to carstenmattner from comment #17)
> BTW, I've tried and failed to see the grey bg color you mentioned happens
> the same with gtk2 but goes unnoticed.

You can see it in your video; the window appears and it's "empty" before getting populated. Or if you resize, you get a grey background before its contents are resized.

> You can try bisecting between a known good version using `git bisect`.

Sorry, I should have asked if you know of any suspected ranges one should try to bisect in. I guess 3.18 vs 3.20 is good enough, but it's important to find the exact last known working release. I don't recall with certainty if 2.18 was totally correct because I wasn't forced to use gtk3 back then due to Firefox's changes.

Is there a way to test this bit of gtk3 in-tree without overwriting the system installation on each bisect step? Like build and then run a locally linked test program that is either statically linking gtk3 or rpath-preferring the build tree libs? That would make bisecting much easier.

> There are compositors that work outside of GNOME. Metacity has a compositor, for instance; KWin has a compositor.

Am I right to interpret that to mean gtk3 is officially supported outside GNOME, as long as there's a compositor running?

Does that then mean the no-compositor case is unsupported?

I am, as I said earlier, using a compositor with an X11 window manager, where this happens, thus that can be ruled out.

It also happens with Firefox 49 under Wayland (last tested with sway, but also Weston earlier) because Firefox crashes if you start it with GDK_BACKEND=wayland, and that's good, because there is a Wayland compositor in place and Firefox's gtk3 backend is running in X11 mode. It does not happen if gtk3-widgetfactory uses the wayland code path under sway, but then dialogs are zoomed-out, not scaled-out, which makes it unusable on screens that are not big.

Note to self: find a way to switch zooming to scaling for ux improvement.

> You can see it in your video; the window appears and it's "empty" before getting populated. Or if you resize, you get a grey background before its contents are resized.

It's not my video, but I'll see if I can reproduce it.

Sorry about the overly long quoted lines. I didn't know bugzilla wouldn't wrap them like the rest. Now I know :(.

The black artifacts can also be observed, when moving other windows on top of GTK3 based applications: https://youtu.be/HkVb9738le4

I think I know what is going wrong here:

* X11 windows do have a background color. When areas are exposed by e.g. moving or resizing a window, that area has to be repainted by the client. However by setting a background color, X11 "pre-fills" that area with the specified color - setting this color to something close to the content's color can help to reduce disturbing artifacts like the black areas observed here.

* GTK3 repaints serverly slower than GTK2 (galculator consists of just a few buttons, and yet on this fast machine (haswell with intel SNA driver) the repaint-lag is clearly visible. It is quite sad there are no automated performance regression tests to track issues like this.

Maybe I can find some time to have a look at the code ...

Normally, you don't want to map a window until after rendering its contents.  That wouldn't make the window contents display any faster, but it would avoid the flash of background color.

Wouldn't mapping cause an expose event right after the window becomes is visible?

(In reply to Clemens Eisserer from comment #23)
> Wouldn't mapping cause an expose event right after the window becomes is
> visible?

Yes, but you would render the already-known contents of the window in immediate response to that event, so you should never see a flash.  You shouldn't wait until an Expose event to do any non-trivial calculations needed for rendering; you should already have your window contents and just supply them when needed.  (This is somewhat different than the compositing case.)

The same black artifacts appear when I move another window on top of a GTK3 window. To me it seems as a combination of a somewhat slow GTK3's paint process and the window background color not set accordingly (therefore un-painted regions are initialized with black until the client is able to render).

We used to always map X window swith background = None which makes X not paint the background color before asking us to draw. I guess this got lost at some point.

GTK3 does no longer set a background color, because the background color would always end up being wrong, in particular now that we draw client-side shadows. Ideally, we'd want to set transparency, but unfortunately the X server doesn't have that option.

ParentRelative and None pixmaps don't work either.
None leads to random crap showing up which is strictly worse than black.
ParentRelative crashes because we use a different Visual than the parent window, so their backgrounds aren't compatible.

So we gave up and currently just set black until somebody comes up with a better idea.

Benjamin: So the backgournd color is no longer set, because it would cause issues with client-side shadows? That is actually good news, as this issue only manifests without a compositor (so no client-side shadows anyway).

(In reply to Clemens Eisserer from comment #28)
> Benjamin: So the backgournd color is no longer set, because it would cause
> issues with client-side shadows? That is actually good news, as this issue
> only manifests without a compositor (so no client-side shadows anyway).

I'm repeating myself, but to be clear:

The only situation where this doesn't happen is if the GTK3 window is drawn natively under Wayland.

With or without an X or Wayland compositor it's still the same flashing as long as GTK3 uses the X code path.

I would love to use Wayland, but Xwayland integration of most stuff is wonky and there's no sufficiently capable replacement for my current environment. Either it's using wlc and inherits the bugs of that compositor or it's better and using libweston but that's just weston itself unfortunately. If a capable env would be built on libweston(-desktop), I might be able to make the switch. One day very soon......

carsten: which compositor are you using? under xfce, as soon as I enable xfwm4's compositor, the black flashing no longer appears.

* compton (X11)
backend = "xr_glx_hybrid";
vsync = "opengl-swc";

The sole reason I run a compositor under X11 is to fix the post-Sandybridge constant tearing with i915.

* Wayland (libweston or wlc) when GDK uses X11

Do you know why the configured GTK3 theme is ignored and things like font settings are completely wrong when GTK3 draws to Wayland, and under the same Wayland session when GTK3 uses X11, then it's the correct settings configured in ~/.config/gtk-3.0? Is there different theme settings for GDK Wayland? If I start gtk3-widget-factory under a Wayland compositor, the theme is wrong, the font is large, and the window doesn't fit in any way. If I start the same GTK3 app under X11, then it's the configured theme and settings. Same if I force GDK to X11 under Wayland. This is surprising.

Running Firefox 50 which uses by default its cairo-gtk3 backend/port under any Wayland compositor, will result in the same issue. But in that mode GTK3 does respect theme settings. I might have to find out why GTK3 in GDK=Wayland ignored settings.

> But in that mode GTK3 does respect theme settings.

s/does/does not/

How do we fix this?

https://bugzilla.gnome.org/show_bug.cgi?id=767212 is about the resizing issue, with patches attached.

https://bugzilla.gnome.org/show_bug.cgi?id=757104 is also related.

FWIW, I can confirm that Sebastian's patch (https://bugzilla.gnome.org/attachment.cgi?id=314092&action=diff)
from https://bugzilla.gnome.org/show_bug.cgi?id=757104 successfully papers over the drawing regression.

*** This bug has been marked as a duplicate of bug 757104 ***

Created attachment 358382 [details]
K3b 'About' dialog shows black flash

This bug affects qt5 apps running under xwayland on my system (Antergos, Gnome 3.26 beta 2, intel hd graphics, modesetting driver).
My screencast shows K3b case.

*** This bug has been marked as a duplicate of bug 748498 ***