[GTK] Graphics regressions in 2.39.1

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

This is a tracker bug. The switch to USE_ANGLE_WEBGL and enablement of WebGL 2 seems to have introduced several regressions for one of our Tech Preview users, including some that are not related to WebGL at all. It seems ANGLE is failing to initialize EGL for at least some users, which was not a problem before; this might be to blame for *all* of the problems? Hopefully we can investigate and resolve the regressions.

If we successfully solve these problems, then we should tell Brent that it's time to land https://github.com/WebKit/WebKit/pull/7079. Otherwise, we might decide to revert the use of USE_ANGLE_WEBGL and ENABLE_WEBGL2, but hopefully it won't come to that.

[Zan Dobersek]

#248221 and #248223 have no relation to WebGL or ANGLE.

[Michael Catanzaro]

Well ANGLE is printing errors when we don't expect it to be used at all. See e.g. https://bugs.webkit.org/show_bug.cgi?id=248223#c10

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #2)
> Well ANGLE is printing errors when we don't expect it to be used at all. See
> e.g. https://bugs.webkit.org/show_bug.cgi?id=248223#c10

See also comment 11 there.

[Carlos Garcia Campos]

I think we are assuming all the issues reported for 2.39 are due to angle, because some people are getting errors from angle when creating the EGL context. So, it's clear there's a problem there, but doesn't mean it's the source of all problems. The big changes between 2.38 and 2.39 are:

 - The ANGLE WebGL and WebGL2: it seems we are failing to create the GL context in some cases.
 
 - Async scrolling refactorings: I merged in 2.38 the commits actually fixing issues, but not all the other refactorings that shouldn't affect the behavior, but maybe there's a bug hidden there causing kinetic scrolling to fail for some people.

 - Threaded rendering disabled by default: this only affects GTK4 builds that used to have threaded rendering enabled. We detected some crashes and decided to disable it. This might be the cause of performance regressions, but it's easy to check because threaded rendering can still be enabled using the env var WEBKIT_NICOSIA_PAINTING_THREADS=4

 - Nested wayland compositor removed: I don't think this affects most of the users that should already be using the wpe renderer.

So, we would need to first find the cause of every regression before deciding to just disable angle or webgl. I know it's a pain, but bisecting is the best solution. I would do it myself if I could reproduce all the issues.

[Kdwk]

> it's easy to check because threaded rendering can still be enabled using the env var WEBKIT_NICOSIA_PAINTING_THREADS=4

I tried setting that env var inside the Flatpak environment and tested again. Same result.

[Michael Catanzaro]

I can't reproduce the problems either.

Unfortunately, asking users to bisect WebKit by building it themselves is not very realistic. We can ask them to use flatpak-bisect to test runtime builds that we've built, but for Tech Preview that only tells us what release introduced the problems, and in this case we already know it's 2.39.1. If we had Canary working, then we could ask to bisect the WebKit runtime and get more granularity, but Canary has been turned off since we switched to GTK 4 because there is no WebKit runtime for GTK 4 yet. So there's no realistic way to ask for more granularity here, unless kdwkleung is willing to try building WebKit manually, which is possible but not easy for newcomers. (But if you're willing to do it, that would help us precisely pinpoint the cause of these problems.)

(In reply to Carlos Garcia Campos from comment #3)
> (In reply to Michael Catanzaro from comment #2)
> > Well ANGLE is printing errors when we don't expect it to be used at all. See
> > e.g. https://bugs.webkit.org/show_bug.cgi?id=248223#c10
> 
> See also comment 11 there.

Ah, you're right, I see. Maybe that bug report just got a little too confused....

(In reply to Carlos Garcia Campos from comment #4)
>  - The ANGLE WebGL and WebGL2: it seems we are failing to create the GL
> context in some cases.

Indeed.

>  - Async scrolling refactorings: I merged in 2.38 the commits actually
> fixing issues, but not all the other refactorings that shouldn't affect the
> behavior, but maybe there's a bug hidden there causing kinetic scrolling to
> fail for some people.

No doubt that's the cause of bug #249199, but could it be related to the blocked bugs here?

(I have noticed keyboard scrolling is unreliable after your keyboard animation work, but so far kdwkleung has only complained about touchpad scrolling.)

>  - Threaded rendering disabled by default: this only affects GTK4 builds
> that used to have threaded rendering enabled. We detected some crashes and
> decided to disable it. This might be the cause of performance regressions,
> but it's easy to check because threaded rendering can still be enabled using
> the env var WEBKIT_NICOSIA_PAINTING_THREADS=4

We know this isn't to blame because kdwkleung tested it already.

>  - Nested wayland compositor removed: I don't think this affects most of the
> users that should already be using the wpe renderer.

We know this isn't to blame because these are bug reports for Tech Preview, which already had WPE renderer, so this did not change.

[Kdwk]

> (But if you're willing to do it, that would help us precisely pinpoint the cause of these problems.)

I am definitely willing, but someone would have to instruct me on what to do, because I have no idea how to do it.

[Michael Catanzaro]

OK, we'll discuss in #epiphany:gnome.org.

[Michael Catanzaro]

All dependent bugs are fixed. Closing.