Bug 165246 – [GTK] Fails to draw in Wayland with enabled compositing mode

• Component: WebKitGTK
• Status: RESOLVED WORKSFORME

[Milan Crha]

This had been reported downstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1398806

and also in GNOME bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=775372

The compositing mode totally breaks whole window rendering under Wayland for some users. The above bugs have screenshots. Disabling it with WEBKIT_DISABLE_COMPOSITING_MODE=1 works.

There are also other side effects of this change, again not for everyone, see:
https://bugzilla.gnome.org/show_bug.cgi?id=774067

It would be nice to have an API to disable it, instead of modifying environment variables in the code.

[Tomas Popela]

As I said in the downstream bug, we are aware of the issue - https://lists.webkit.org/pipermail/webkit-gtk/2016-November/002863.html

[Carlos Garcia Campos]

It would be interesting to check if it also fails when using glReadPixels instead of gdk_gl

[Milan Crha]

If you'd have any test patches then I'm sure either Tomas or I can create a test package of the WebKitGTK+ for the Fedora users to give it a try.

[Michael Catanzaro]

(In reply to comment #1)
> As I said in the downstream bug, we are aware of the issue -
> https://lists.webkit.org/pipermail/webkit-gtk/2016-November/002863.html

Well just because it makes sense to disable AC for Evolution, doesn't mean that's an acceptable resolution to this bug. :)

I think we need glxinfo output here as well.

(In reply to comment #2)
> It would be interesting to check if it also fails when using glReadPixels
> instead of gdk_gl

I guess easiest way to test would be to use the 2.13.92 release and see if that works?

[Michael Catanzaro]

Honestly, I've gotten such a large number of complaints that rendering is broken in 2.14, I'm sorely tempted to disable it in Ephy as well. Graphics folks have failed to present a single website that doesn't work without it, there are clearly many very serious bugs, and performance without it is more than sufficient for desktop use-cases. We should just turn it off unconditionally until some company decides to invest in making it work properly. It's not OK right now, 2.14 is still less reliable than 2.12 several months after release.

[Milan Crha]

I second your feelings. I'm afraid that we even would lose users due to them thinking that the evolution is completely broken, while it would be hard to explain that it's not only the evolution, but anything what uses webKit2, and then you telling them it's not about WebKit2 (partly), but about their drivers. Phew, I can imagine what they would think about all of us...

Thus, if you can, please disable composite rendering by default in 2.14.3 and let's hope that distros which tend not to update their packages that often will pick such important change too. (/me crosses fingers)

I would suggest to change the related code, the one where you check for WEBKIT_DISABLE_COMPOSITING_MODE, to not test only existence, but to test also the value, which would look like:

   const gchar *value = g_getenv ("WEBKIT_DISABLE_COMPOSITING_MODE");
   if (!value) {
      // disable compositing mode
      // disable the force something, what preceded with the other env
      //     variable or being forced by a compiler switch (#define)
   } else if (g_strcmp0 (value, "1") == 0) {
      // disable compositing mode
   } else {
      // enable compositing mode
   }

If a user would use "WEBKIT_DISABLE_COMPOSITING_MODE=blabla" then it's his/her fault, as the value will be expected "0" or "1", where "0" (anything but "1") enables compositing mode.

Ideally if you also add relevant APIs to override the state for the applications, without the need to modify environment variables.

[Michael Catanzaro]

(In reply to comment #6)
> I would suggest to change the related code, the one where you check for
> WEBKIT_DISABLE_COMPOSITING_MODE, to not test only existence, but to test
> also the value

https://trac.webkit.org/changeset/209391

[Milan Crha]

(In reply to comment #7)
> (In reply to comment #6)
> > I would suggest to change the related code, the one where you check for
> > WEBKIT_DISABLE_COMPOSITING_MODE, to not test only existence, but to test
> > also the value
> 
> https://trac.webkit.org/changeset/209391

Nice.

Unless I misread anything, g_strcmp0() returns -1, 0, 1; getenv() returns NULL if not found. That makes the code trigger (disable compositing mode) even when the variable is not defined. That feels like you've covered the comment #5 already.

[Michael Catanzaro]

Nope, you're right, Tom and I are the ones who missed that, it's not what we were trying to do there.

[Carlos Garcia Campos]

(In reply to comment #5)
> Honestly, I've gotten such a large number of complaints that rendering is
> broken in 2.14, I'm sorely tempted to disable it in Ephy as well. Graphics
> folks have failed to present a single website that doesn't work without it,
> there are clearly many very serious bugs, and performance without it is more
> than sufficient for desktop use-cases. We should just turn it off
> unconditionally until some company decides to invest in making it work
> properly. It's not OK right now, 2.14 is still less reliable than 2.12
> several months after release.

I guess you are talking only about wayland, right? I know some people also having problems under X11, but I haven't seen so many complains. I think the main issue in wayland is that we also use GL on the UI process side, and gdk_gl is probably not ready or mature enough yet. That's why I asked if that also happened when using glReadPixels. We can always disable everything that doesn't work, but we can also try to fix and find alternative solutions in the meantime. For example, in this case if the problem is gdk_gl, let's try using glReadPixels always. Another idea would be to go back to enter/leave AC mode only when required. I agree it's a waste of time and memory having AC enable to show about:blank.

[Michael Catanzaro]

(In reply to comment #10)
> I guess you are talking only about wayland, right?

I think users are complaining with X11 as well. But yes, I'm primarily concerned with Wayland. The problem is that it works fine for you and me regardless, but a bunch of users (including many on IRC who don't report bugs) seem to have hardware-specific issues, and there's nothing we can do except shrug and say "maybe your graphics driver is broken" -- then everyone's dissatisfied as nobody knows what to do with such a bug. The most important problem is that no WebKit developer except you is looking at the bugs at all.

> I know some people also
> having problems under X11, but I haven't seen so many complains. I think the
> main issue in wayland is that we also use GL on the UI process side, and
> gdk_gl is probably not ready or mature enough yet. That's why I asked if
> that also happened when using glReadPixels.

Well we need to prepare some test patch or something, or we'll never get an answer to that question.

> We can always disable everything
> that doesn't work, but we can also try to fix and find alternative solutions
> in the meantime. For example, in this case if the problem is gdk_gl, let's
> try using glReadPixels always. Another idea would be to go back to
> enter/leave AC mode only when required. I agree it's a waste of time and
> memory having AC enable to show about:blank.

I don't think AC mode is actually required on any website that triggers it; in fact, my experience has historically been that websites that trigger it (reuters.com, github.com) render much faster and more reliably without it.

It occurs to me that there is one really big downside to disabling it, though, which is that we'll have to deal with bug #126122 once again. That's a major problem, so we're out of luck either way.

[Davide Repetto]

Created attachment 296422 [details]
Glxinfo of AMD RS780L [Radeon 3000] (which uses r600 in mesa)

I am experiencing this problem on my machine under MATE with no compositing whatsoever.

I'm seeing very similar partial freezes on other apps. Eg. in Opera, VLC and MPV.
The latter two of which don't seem especially related to webkit...

It is also interesting to note that it is possible to work around the problem in VLC, by changing the video output mode and in Opera, by disabling the hardware acceleration.

[Carlos Alberto Lopez Perez]

(In reply to comment #11)
> (In reply to comment #10)
> > I guess you are talking only about wayland, right?
> 
> I think users are complaining with X11 as well. But yes, I'm primarily
> concerned with Wayland. The problem is that it works fine for you and me
> regardless, but a bunch of users (including many on IRC who don't report
> bugs) seem to have hardware-specific issues, and there's nothing we can do
> except shrug and say "maybe your graphics driver is broken" -- then
> everyone's dissatisfied as nobody knows what to do with such a bug. The most
> important problem is that no WebKit developer except you is looking at the
> bugs at all.
> 

An idea is to build a black-list of hardware and drivers that we know are broken with WebKitGTK+.

At run-time we fetch the information about the hardware and drivers/versions of the machine, and by default we only enable AC if the combination is not blacklisted.

When a user reports a bug about rendering broken with WebKitGTK+, we can ask the information about the hardware and drivers/versions and we blacklist it. The blacklist entry should contain a link to a bug in this bugzilla where the bug itself would be eventually fixed (if it's an issue on WebKit itself rather than on the drivers). But in the meanwhile, at least we ensure that this problematic hardware/driver gets blacklisted ASAP, and that the user can use WebKitGTK+ without major issue on the hardware.


Chrome does this: they have an extensive list of hardware and drivers that should be avoided. [1] This is a good resource to start building this list.



[1] https://chromium.googlesource.com/chromium/deps/gpu/software_rendering_list/+/467471226a0453e9613db84879fa0dcabc149689/software_rendering_list.json

[Miguel Gomez]

Is there any update on this? My bet is that this is a problem in the ATI driver, mostly because the rendering issue doesn't look like a WebKit issue, and also because according to https://bugzilla.redhat.com/show_bug.cgi?id=1398806#c11, it got fixed for Simon after an update that included a new Mesa release.

Is there anyone still able to reproduce this?

[Michael Catanzaro]

Closing this bug since there was no response to Miguel's question. Feel free to reopen if you can still reproduce this issue.