Bug 228268 – [GTK4] [REGRESSION] Rendering on Nvidia is terribly broken, almost a blank screen

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Emil Sayahi]

Hello! This is my first time submitting a bug report, so apologies if I'm not as helpful as I should be.

I'm currently successfully building `libwebkitgtk-5.0`, and I've embedded it as part of developing a new browser project.
I was originally using the stable release of WebKitGTK from the Arch Linux package repositories, but as part of porting my browser to GTK4 I've had to recompile the library myself for GTK4 support (here's the script I wrote to do this: https://raw.githubusercontent.com/Dirout/oku/50c1bd443ac50943b359b16e9d3a140faa604c89/build-dependencies.sh)

Presently, this build of WebKitGTK is completely blank—no content or developer tools menu elements visible—unless I select and drag something offscreen, at which point it becomes visible until I let go of the mouse again.
Perhaps this rendering bug is connected to the fact that I have an Nvidia GPU? I'll need to do further testing on an old laptop I have somewhere.

Additionally, almost all page loads fail while emitting any of the following warnings:
```
(process:70483): GLib-Net-WARNING **: 17:44:39.051: ../glib-networking/tls/gnutls/gtlscertificate-gnutls.c:161: invalid property id 3 for "private-key" of type 'GParamBoxed' in 'GTlsCertificateGnutls'

(process:67609): GLib-GIO-WARNING **: 17:13:47.931: ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 12 for "protocol-version" of type 'GParamEnum' in 'GTlsClientConnectionGnutls'

(process:67609): GLib-GIO-WARNING **: 17:13:47.931: ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 13 for "ciphersuite-name" of type 'GParamString' in 'GTlsClientConnectionGnutls'
```

In the browser, the page contents simply are 'Error reading data from TLS socket: The specified session has been invalidated for some reason.' or, sometimes, 'Could not parse HTTP response'.
This is not always reproducible, sometimes, rarely, page loads just randomly work, but 99% of the time they don't.
I've tried Google, YouTube, Reddit, 'https://example.com', and 'https://www.iana.org/domains/reserved'.
My best guess is that this is some bug introduced in `libsoup-3.0`, maybe in its `glib` dependency? I had to recompile `libsoup` as well, for the same reasons I had to recompile WebKitGTK.

My biggest concern, by far, is the visibility issue. It does appear that things are being rendered, it's just pure white unless I drag things away with my mouse.
To be clear, every other GUI element of my GTK app is visible and working properly, it's just the WebView which is experiencing this.

I'm running Arch Linux with GNOME DE, X11 (because Nvidia GPU), using proprietary Nvidia drivers, with all installed packages up-to-date.

[Emil Sayahi]

Ah, interesting. I've discovered the rendering isn't actually pure white, but slightly darker. I ramped up my Night Shift intensity in the GNOME settings app, and I can slightly make out some text from the WebView in a very light grey.
The developer tools, accessed from the 'Inspect Element' context menu option, are completely invisible, however.
Context menus, like the rest of the GTK elements, appear to be working just fine.

[Emil Sayahi]

I've made a discovery regarding the page loading failure.
Based on the errors, I guessed it was an issue with HTTPS.
I've been able to connect to 'http://neverssl.com/' and 'http://example.com' (as opposed to the https version) consistently.
I'm now updating the bug report title to mention this issue

[Michael Catanzaro]

(In reply to Emil Sayahi from comment #0)
> Additionally, almost all page loads fail while emitting any of the following
> warnings:
> ```
> (process:70483): GLib-Net-WARNING **: 17:44:39.051:
> ../glib-networking/tls/gnutls/gtlscertificate-gnutls.c:161: invalid property
> id 3 for "private-key" of type 'GParamBoxed' in 'GTlsCertificateGnutls'
> 
> (process:67609): GLib-GIO-WARNING **: 17:13:47.931:
> ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 12 for
> "protocol-version" of type 'GParamEnum' in 'GTlsClientConnectionGnutls'
> 
> (process:67609): GLib-GIO-WARNING **: 17:13:47.931:
> ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 13 for
> "ciphersuite-name" of type 'GParamString' in 'GTlsClientConnectionGnutls'
> ```

This means your glib is too old: somehow, you built glib-networking against a newer glib than you're using at runtime. You need to make sure that the software in your runtime environment is never older than the software in your build environment.

[Emil Sayahi]

(In reply to Michael Catanzaro from comment #3)
> (In reply to Emil Sayahi from comment #0)
> > Additionally, almost all page loads fail while emitting any of the following
> > warnings:
> > ```
> > (process:70483): GLib-Net-WARNING **: 17:44:39.051:
> > ../glib-networking/tls/gnutls/gtlscertificate-gnutls.c:161: invalid property
> > id 3 for "private-key" of type 'GParamBoxed' in 'GTlsCertificateGnutls'
> > 
> > (process:67609): GLib-GIO-WARNING **: 17:13:47.931:
> > ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 12 for
> > "protocol-version" of type 'GParamEnum' in 'GTlsClientConnectionGnutls'
> > 
> > (process:67609): GLib-GIO-WARNING **: 17:13:47.931:
> > ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 13 for
> > "ciphersuite-name" of type 'GParamString' in 'GTlsClientConnectionGnutls'
> > ```
> 
> This means your glib is too old: somehow, you built glib-networking against
> a newer glib than you're using at runtime. You need to make sure that the
> software in your runtime environment is never older than the software in
> your build environment.

I built and installed GLib from the GNOME GitLab. I then used that very same version when compiling `libsoup-3.0`. You can see this in the script I'm using to build WebKit (https://raw.githubusercontent.com/Dirout/oku/90034f7d55649026a61ead2e934226870a1cb607/build-dependencies.sh).
Just to ensure this is the case, I've rebuilt and reinstalled, in order of mentioning, GLib, Libsoup, and WebKitGTK. Afterwards, I rebuilt my browser.
Neither issue has been resolved, and I continue to receive the very same GLib-GIO warnings regarding HTTPS.

[Michael Catanzaro]

Try building glib-networking as well?

[Emil Sayahi]

(In reply to Michael Catanzaro from comment #5)
> Try building glib-networking as well?

Thanks, that fixed it. Building & installing GLib, glib-networking, libsoup, and then WebKit, in that order, now allows for successful HTTPS connections. Now removing mention of this from the bug report title.

Now all that remains is the original issue, the blanked out WebView. It is being properly rendered somehow, as dragging page elements like images or highlighted text makes them visible while dragged, but the actual WebView GTK widget itself is almost pure white.

[Emil Sayahi]

I've compiled the MiniBrowser, and this rendering issue also affects that.
Now I know for certain it's not something related to my code or browser.

[Emil Sayahi]

Someone has tested and informed me via Reddit that this bug is present on Nvidia GPUs, but not Intel graphics.
Source: https://reddit.com/r/GTK/comments/owvlen/how_does_gtk4_webkit_render_for_you/h89w498/

This would be a regression, as the stable, GTK3 releases of WebKitGTK do not have this terrible rendering bug on Nvidia.

[Lauro Moura]

Adding bug192879 as it might be related (changed the isInAcceleratedCompositingMode implementation)

[Lauro Moura]

Sorry. Wrong bugzilla page... #facepalm

[Michael Catanzaro]

Hi Emil, can you confirm that this is still broken] I expect so, since nobody has attempted to fix it, but it's been half a year, and occasionally the bug gremlins take pity and fix things for us if we wait long enough....

[Jan]

Hello Michael,

I can't speak for myself, but the bug seems to still be present in the version that is currently shipped in "org.gnome.Platform" master. So probably a somewhat recent version of webkit master/main?

I'm getting feedback from people trying the Gtk4 port of my feed reader.

https://gitlab.com/news-flash/news_flash_gtk/-/issues/318
https://gitlab.com/news-flash/newsblur_api/-/issues/2#note_899952104

[Patrick Griffis]

Created attachment 460310 [details]
Picture of broken rendering

Broken rendering on nvidia as of git commit 54f1485d92416e5b27b10fef5b47e9c4844f53d7

[Emil Sayahi]

(In reply to Michael Catanzaro from comment #11)
> Hi Emil, can you confirm that this is still broken] I expect so, since
> nobody has attempted to fix it, but it's been half a year, and occasionally
> the bug gremlins take pity and fix things for us if we wait long enough....

I forgot this was still open. Yes, it remains broken for me to this date. On Arch Linux with an NVIDIA GTK 970, all up-to-date packages (NVIDIA drivers, GNOME 42, webkit2gtk-5.0, GTK4 dev packages, etc).

I found [this video](https://youtu.be/xm6AiWzdERc) of someone trying the GTK 4 branch of GNOME Web and they appear to encounter the same problem unless they force dark mode. That doesn't appear to be a fix for me

[Emil Sayahi]

Created attachment 460638 [details]
Screenshot of correct rendering with dark mode

To further add to my previous comment:
After switching my browser over to `libadwaita` and enforcing a dark mode through `libadwaita::StyleManager` as opposed to `gtk4::Settings.gtk_application_prefer_dark_theme`, the rendering does appear to get fixed, as that YouTube video that I'd found appeared to show.

[Emil Sayahi]

Created attachment 460639 [details]
Screenshot showing rendering irregularity with dark mode

It appears, however, that things still appear to be abnormally bright, as demonstrated with this screenshot of Reddit in my own browser.
This is not the case in Google Chrome or Firefox (will post comparison screenshot in next comment).

[Emil Sayahi]

Created attachment 460640 [details]
Screenshot showing correct rendering in other browser

This is Reddit in Google Chrome, as a point of comparison to show how bright WebKitGTK still appeared, even when things were made visible with the switch to `libadwaita`'s forced dark mode.

I tried taking a screenshot in pre-GTK4 GNOME Web instead of Google Chrome, but it appears running my own browser causes the WebKitGTK component to become non-functional in GNOME Web until I restart my PC. This is true in the reverse—when, last night, I switched my browser to `libadwaita` (it was already using GTK4, FYI) the WebKit component decided to stop working completely, spitting out errors in the terminal, while GNOME Web operated fine. This remained the case until I restarted my PC this morning and attempted running my own browser again, when it started magically working without any code changes, but apparently caused GNOME Web to break.

If you want to tinker around with my GTK4 + libadwaita + webkit2gtk-5.0 web browser to debug things yourself, the source code is here: https://github.com/Dirout/oku/ (latest commit is https://github.com/Dirout/oku/commit/dda8ee0c11e520a78c69e77e0ba00726bb032436 as of posting this comment).
To run it, install the Rust compiler toolchain and run `cargo run --release` inside the source code directory.

[Michael Catanzaro]

Looks like this is going to be a blocker for GTK 4. Does Igalia plan to investigate this? I can try to pull in Red Hat graphics people if that would help?

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #18)
> Looks like this is going to be a blocker for GTK 4. Does Igalia plan to
> investigate this? I can try to pull in Red Hat graphics people if that would
> help?

This offer is still available.

[Michael Catanzaro]

I will ask Red Hat to see if we might help with this.

[Michael Catanzaro]

Created attachment 464540 [details]
Test patch for glvnd

Hi, we'd like an NVIDIA user who is willing to rebuild glvnd to try a debug patch to see if we have a synchronization problem in GTK and/or WebKit. This patch is a hack that's only suitable for debug purposes. Goal is to see if this fixes the rendering issue or if it makes no difference.

Emil, if you're still around, I see you're using Arch Linux. How comfortable would you be with rebuilding Arch's glvnd package with this patch included?

[Michael Catanzaro]

BTW, this test will only work if Arch actually uses glvnd, but I think it does based on this old news article: https://archlinux.org/news/mesa-with-libglvnd-support-is-now-in-testing/. Would be helpful to confirm that for certain.

[Michael Catanzaro]

Comment on attachment 464540 [details]
Test patch for glvnd

Um, the patch is broken. Sec. :)

[Michael Catanzaro]

Created attachment 464541 [details]
glvnd debug patch, try #2

[Adrian Perez]

(In reply to Michael Catanzaro from comment #22)
> BTW, this test will only work if Arch actually uses glvnd, but I think it
> does based on this old news article:
> https://archlinux.org/news/mesa-with-libglvnd-support-is-now-in-testing/.
> Would be helpful to confirm that for certain.

Yes, Arch has been using libglvnd for a good while, and it's the
provider chosen by default for the “libgl” virtual package:

  https://archlinux.org/packages/extra/x86_64/libglvnd/

[Michael Catanzaro]

Can anyone at least confirm the bug still exists?

[Jan]

I've been trying to get some testers for the patch. But it seems like people are expecting some ready to run binaries. Not having to compile or install anything:

https://gitlab.com/news-flash/news_flash_gtk/-/issues/318

[Michael Catanzaro]

Alas, for this bug we really do need someone who is comfortable with modifying libglvnd. If using via flatpak, that would require rebuilding the runtime.

Rebuilt libglvnd with patch from Michael. Can confirm issue still present in MiniBrowser example.

Running Nvidia 525.85.05
uname -a: Linux party 6.1.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 24 Jan 2023 21:07:04 +0000 x86_64 GNU/Linux

Webkit5 installed from repo.
ldd shows patched library is being linked. 
If i should rebuild wk-5.0 from source, it will wait till tomorrow, when i get my new cpu home, because i've got no patience for building on a 4-core machine

[Michael Catanzaro]

No need to build WebKit. That was exactly the testing that we needed. Was hoping you'd say it was fixed, but oh well. Thanks.

(In reply to Michael Catanzaro from comment #30)
> No need to build WebKit. That was exactly the testing that we needed. Was
> hoping you'd say it was fixed, but oh well. Thanks.

If it "just worked"™️ we'd all have no job security ;)

feel free to ping me here or on Mastodon [e-mail] if you need testing or further debug traces at some point

[Sonny Piers]

In case it's helpful, an NVIDIA Tangram user has reported to have washed out colors instead of completely white.

https://github.com/sonnyp/Tangram/issues/231

[Jan]

> In case it's helpful, an NVIDIA Tangram user has reported to have washed out colors instead of completely white.

I thought this was already known, so I didn't report it. But yes, "dark" content is visible, but way brighter than it should be:

https://gitlab.com/news-flash/news_flash_gtk/-/issues/419

[Michael Catanzaro]

That might be worth a separate bug report.

I think it's safe to say we don't know anything about problems with NVIDIA except for what you see here in this issue.

[José]

Hey! I’m the nvidia tangram user. I’m comfortable compiling for source. What can I do to help?

[Michael Catanzaro]

Hmm, at this time I need to ping our graphics developers again because so far we have all the info they requested. But I'm glad you're here as no doubt we'll need you to test something soon enough. ;)

[Michael Catanzaro]

So bad news, Red Hat decided we'll only support WebKitGTK for nouveau users. We might have some further debugging tips to provide but otherwise won't be working on this after all.

[Erik Kurzinger]

Hey guys, I had a look at this with a debug build of the NVIDIA driver which might help. I tried Michael's suggestion of adding a glFinish() before glX/eglMakeCurrent but that didn't have an effect. For the record I'm using the GTK4 app "newsflash", which includes a WebKit view, and currently that area is completely blank.

What seems to be the issue is that the alpha channel of the pixmap that the WebKit process renders to is zero, but the GUI process interprets it as ARGB data. If I hack cairo to always interpret the data as XRGB instead it fixes the problem for me.

I'm still not sure whether it's a driver bug or an issue in WebKit, but at least this narrows it down somewhat. The pixmap *is* depth-32 so it's a bit strange that no alpha data is getting written.

[Erik Kurzinger]

Ok. The problem is that while the WebKit process chooses a depth-32 X11 visual for its window (in PlatformDisplayX11::visual), the associated GLXFBConfig doesn't actually have an alpha channel. So it ends up rendering in RGB.

It looks like Chromium devs struggled with a similar problem years ago [1]. There's not really a reliable way to choose a suitable X11 visual without calling into GLX, so fixing this might be a bit tricky with the current architecture.

Also, a separate issue is that GLContextGLX::createWindowContext includes "GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, GL_FALSE" in its glXChooseFBConfig criteria, which  causes that function to fail to find any configs. Is there a reason for doing that? SRGB framebuffers are disabled by default even if the config supports them, so it shouldn't be necessary, right?

Regardless, though, even if that criterion is removed, it will find a config but glXMakeCurrent will fail because you can't make an XRGB drawable current to an ARGB context. So the visual thing also needs to be fixed somehow.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=369209

[Michael Catanzaro]

Thanks for looking into this.

So I don't understand graphics much, but I do know that we do not depend on GLX anymore -- EGL is mandatory nowadays -- so talk about GLX is a red flag because we're not using that anymore. So I think you've been debugging an older version of WebKitGTK with different graphics architecture? The current stable release is 2.40.0 and the last release to use GLX was 2.38. There's probably no point in debugging 2.38 at this point. (I think the GLX code is still present in 2.40, but unused. In main it has been removed.)

[Jan]

Erik mentioned "newsflash" which is indeed still on the old webkit2gtk-5.0 API.
The new API was just released and there are still no rust bindings for it.

[Erik Kurzinger]

I used newsflash because a few of the earlier comments mentioned it.

Are we sure that the issue is actually still present with 2.40? I tried the midori browser, which does use 2.40, but that seems to work fine on my system.

[Michael Catanzaro]

(In reply to Erik Kurzinger from comment #42)
> Are we sure that the issue is actually still present with 2.40?

I'm not sure. I hope we didn't have you doing a wild goose chase. Could someone who is able to reproduce the problem (e.g. cpcp800) please confirm this is still broken with 2.40.0?

For reference, we switched from GLX to EGL in https://commits.webkit.org/254751@main (present in 2.40, not in 2.38) and removed the code in https://commits.webkit.org/261741@main (will be present in 2.42, not in 2.40).

[Craig]

Hello.  I have the same issue with Epiphany 44.1 flatpak which uses webkit 2.40.  My laptop uses the older proprietary nvidia-340 and it was suggested on irc I include webkit://gpu text.  Note this page also renders blank, but I can still copy and paste from it.

Copy to clipboard
Version Information
WebKit version
WebKitGTK 2.40.0 (tarball)
Operating system
Linux 5.4.0-146-generic #163~18.04.1-Ubuntu SMP Mon Mar 20 15:02:59 UTC 2023 x86_64
Desktop
Enlightenment
Cairo version
1.16.0 (build) 1.16.0 (runtime)
GStreamer version
1.20.5 (build) GStreamer 1.20.5 (runtime)
GTK version
4.10.1 (build) 4.10.1 (runtime)
Display Information
Type
X11
Screen geometry
0,0 1920x1080
Screen work area
0,0 1920x1080
Depth
24
Bits per color component
8
DPI
96
Hardware Acceleration Information
Policy
always
WebGL enabled
Yes
API
OpenGL ES 2 (libepoxy)
Native interface
GLX
GL_RENDERER
GeForce GT 330M/PCIe/SSE2
GL_VENDOR
NVIDIA Corporation
GL_VERSION
OpenGL ES 2.0 340.108
GL_SHADING_LANGUAGE_VERSION
OpenGL ES GLSL ES 1.00
GL_EXTENSIONS
GLX_VERSION
1.4
GLX_VENDOR
NVIDIA Corporation
GLX_EXTENSIONS
GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_swap_control GLX_EXT_swap_control GLX_EXT_swap_control_tear GLX_EXT_buffer_age GLX_ARB_create_context GLX_ARB_create_context_profile GLX_NV_float_buffer GLX_ARB_fbconfig_float GLX_EXT_fbconfig_packed_float GLX_EXT_texture_from_pixmap GLX_EXT_framebuffer_sRGB GLX_NV_present_video GLX_NV_copy_image GLX_NV_multisample_coverage GLX_NV_video_capture GLX_EXT_create_context_es_profile GLX_EXT_create_context_es2_profile GLX_ARB_create_context_robustness GLX_NV_delay_before_swap GLX_EXT_stereo_tree

[Michael Catanzaro]

I think we should backport at least the protocol handler changes from 261741@main to 2.40 branch. Since the GLX code is really completely unused in 2.40 (right?) but without that commit, we still print GLX rather than EGL stuff in webkit://gpu, which is not what we need to see here.

> OpenGL ES 2 (libepoxy)

Hm, OpenGL ES is supposed to be supported and working, but it's pretty unusual for a desktop system, and I bet it's rarely tested....

[Craig]

Terminal output:

$ flatpak run org.gnome.Epiphany

(epiphany:2): epiphany-WARNING **: 19:18:28.252: Failed to search secrets in password schema: org.freedesktop.DBus.Error.ServiceUnknown
Gsk-Message: 19:18:28.468: Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkX11Toplevel': Compilation failure in shader.
Source Code:   1| #version 100
  2| #define GSK_GLES 1
  3| #define NO_CLIP 1
  4| #ifndef GSK_LEGACY
  5| precision highp float;
  6| #endif
  7|
  8| #if defined(GSK_GLES) || defined(GSK_LEGACY)
  9| #define _OUT_ varying
 10| #define _IN_ varying
 11| #define _GSK_ROUNDED_RECT_UNIFORM_ vec4[3]
 12| #else
 13| #define _OUT_ out
 14| #define _IN_ in
 15| #define _GSK_ROUNDED_RECT_UNIFORM_ GskRoundedRect
 16| #endif
 17|
 18|
 19| struct GskRoundedRect
 20| {
 21|   vec4 bounds; // Top left and bottom right
 22|   // Look, arrays can't be in structs if you want to return the struct
 23|   // from a function in gles or whatever. Just kill me.
 24|   vec4 corner_points1; // xy = top left, zw = top right
 25|   vec4 corner_points2; // xy = bottom right, zw = bottom left
 26| };
 27|
 28| // Transform from a C GskRoundedRect to what we need.
 29| GskRoundedRect
 30| gsk_create_rect(vec4[3] data)
 31| {
 32|   vec4 bounds = vec4(data[0].xy, data[0].xy + data[0].zw);
 33|
 34|   vec4 corner_points1 = vec4(bounds.xy + data[1].xy,
 35|                              bounds.zy + vec2(data[1].zw * vec2(-1, 1)));
 36|   vec4 corner_points2 = vec4(bounds.zw + (data[2].xy * vec2(-1, -1)),
 37|                              bounds.xw + vec2(data[2].zw * vec2(1, -1)));
 38|
 39|   return GskRoundedRect(bounds, corner_points1, corner_points2);
 40| }
 41|
 42| vec4
 43| gsk_get_bounds(vec4[3] data)
 44| {
 45|   return vec4(data[0].xy, data[0].xy + data[0].zw);
 46| }
 47|
 48| vec4 gsk_premultiply(vec4 c) {
 49|   return vec4(c.rgb * c.a, c.a);
 50| }
 51|
 52| vec4 gsk_scaled_premultiply(vec4 c, float s) {
 53|   // Fast version of gsk_premultiply(c) * s
 54|   // 4 muls instead of 7
 55|   float a = s * c.a;
 56|
 57|   return vec4(c.rgb * a, a);
 58| }
 59| uniform mat4 u_projection;
 60| uniform mat4 u_modelview;
 61| uniform float u_alpha;
 62|
 63| #if defined(GSK_GLES) || defined(GSK_LEGACY)
 64| attribute vec2 aPosition;
 65| attribute vec2 aUv;
 66| attribute vec4 aColor;
 67| attribute vec4 aColor2;
 68| _OUT_ vec2 vUv;
 69| #else
 70| _IN_ vec2 aPosition;
 71| _IN_ vec2 aUv;
 72| _IN_ vec4 aColor;
 73| _IN_ vec4 aColor2;
 74| _OUT_ vec2 vUv;
 75| #endif
 76|
 77| // amount is: top, right, bottom, left
 78| GskRoundedRect
 79| gsk_rounded_rect_shrink (GskRoundedRect r, vec4 amount)
 80| {
 81|   vec4 new_bounds = r.bounds + vec4(1.0,1.0,-1.0,-1.0) * amount.wxyz;
 82|   vec4 new_corner_points1 = r.corner_points1;
 83|   vec4 new_corner_points2 = r.corner_points2;
 84|
 85|   if (r.corner_points1.xy == r.bounds.xy) new_corner_points1.xy = new_bounds.xy;
 86|   if (r.corner_points1.zw == r.bounds.zy) new_corner_points1.zw = new_bounds.zy;
 87|   if (r.corner_points2.xy == r.bounds.zw) new_corner_points2.xy = new_bounds.zw;
 88|   if (r.corner_points2.zw == r.bounds.xw) new_corner_points2.zw = new_bounds.xw;
 89|
 90|   return GskRoundedRect (new_bounds, new_corner_points1, new_corner_points2);
 91| }
 92|
 93| void
 94| gsk_rounded_rect_offset(inout GskRoundedRect r, vec2 offset)
 95| {
 96|   r.bounds.xy += offset;
 97|   r.bounds.zw += offset;
 98|   r.corner_points1.xy += offset;
 99|   r.corner_points1.zw += offset;
100|   r.corner_points2.xy += offset;
101|   r.corner_points2.zw += offset;
102| }
103|
104| void gsk_rounded_rect_transform(inout GskRoundedRect r, mat4 mat)
105| {
106|   r.bounds.xy = (mat * vec4(r.bounds.xy, 0.0, 1.0)).xy;
107|   r.bounds.zw = (mat * vec4(r.bounds.zw, 0.0, 1.0)).xy;
108|
109|   r.corner_points1.xy = (mat * vec4(r.corner_points1.xy, 0.0, 1.0)).xy;
110|   r.corner_points1.zw = (mat * vec4(r.corner_points1.zw, 0.0, 1.0)).xy;
111|
112|   r.corner_points2.xy = (mat * vec4(r.corner_points2.xy, 0.0, 1.0)).xy;
113|   r.corner_points2.zw = (mat * vec4(r.corner_points2.zw, 0.0, 1.0)).xy;
114| }
115|
116| #if defined(GSK_LEGACY)
117| // Can't have out or inout array parameters...
118| #define gsk_rounded_rect_encode(r, uni) uni[0] = r.bounds; uni[1] = r.corner_points1; uni[2] = r.corner_points2;
119| #else
120| void gsk_rounded_rect_encode(GskRoundedRect r, out _GSK_ROUNDED_RECT_UNIFORM_ out_r)
121| {
122| #if defined(GSK_GLES)
123|   out_r[0] = r.bounds;
124|   out_r[1] = r.corner_points1;
125|   out_r[2] = r.corner_points2;
126| #else
127|   out_r = r;
128| #endif
129| }
130|
131| #endif
132|
133| // blend.glsl
134|
135| void main() {
136|   gl_Position = u_projection * u_modelview * vec4(aPosition, 0.0, 1.0);
137|
138|   vUv = vec2(aUv.x, aUv.y);
139| }
140|
141| // FRAGMENT_SHADER:

Error Message:
0(30) : error C7551: OpenGL first class arrays require #version 120
0(43) : error C7551: OpenGL first class arrays require #version 120
0(120) : error C7551: OpenGL first class arrays require #version 120




Cannot create EGL sharing context: error binding OpenGL API (EGL_BAD_PARAMETER)
Cannot create EGL sharing context: error binding OpenGL API (EGL_BAD_PARAMETER)

[Craig]

The current devel version if far less verbose; it flat out refuses to run, claiming it needs one of 3 requirements.  I apparently meet 2 out of 3.

bodhi@VPCF115FM:~$ flatpak run org.gnome.Epiphany.Devel

(epiphany:2): epiphany-WARNING **: 20:13:12.716: Failed to search secrets in password schema: org.freedesktop.DBus.Error.ServiceUnknown
No provider of glGenSamplers found.  Requires one of:
    Desktop OpenGL 3.3
    GL_ARB_sampler_objects
    OpenGL ES 3.0
bodhi@VPCF115FM:~$ glxinfo|grep "OpenGL version"
OpenGL version string: 3.3.0 NVIDIA 340.108
bodhi@VPCF115FM:~$ glxinfo|grep GL_ARB_sampler_objects
    GL_ARB_sample_shading, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map,
    GL_ARB_sample_shading, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map,
bodhi@VPCF115FM:~$ glxinfo|grep "OpenGL ES profile version"
OpenGL ES profile version string: OpenGL ES 2.0 NVIDIA 340.108 340.108
bodhi@VPCF115FM:~$

[Michael Catanzaro]

(In reply to Craig from comment #47)
> The current devel version if far less verbose; it flat out refuses to run,
> claiming it needs one of 3 requirements.  I apparently meet 2 out of 3.

After discussing this with Benjamin, it looks like this is actually required by GTK 4, not by WebKit. Are you able to run any other GTK 4 applications?

[Craig]

(In reply to Michael Catanzaro from comment #48)
 
> After discussing this with Benjamin, it looks like this is actually required
> by GTK 4, not by WebKit. Are you able to run any other GTK 4 applications?

I am using an older distro and don't believe I have anything GTK4 already, so I installed gnome-calculator flatpak from gnome-nightly to test, and indeed it fails with the same error.

$ flatpak run org.gnome.Calculator.Devel
No provider of glGenSamplers found.  Requires one of:
    Desktop OpenGL 3.3
    GL_ARB_sampler_objects
    OpenGL ES 3.0
$

[Michael Catanzaro]

Craig reported https://gitlab.gnome.org/GNOME/gtk/-/issues/5858 since that is indeed a problem with using any GTK 4 apps.

[Alberto Garcia]

Hello,

I have a report from an nVidia user that says that WebKitGTK 2.40.3 works fine but after upgrading to 2.41.6 it stops working (but only the GTK3 builds).

This is all with Debian unstable on an X11 GNOME session:

- (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.0. its MiniBrowser stops working. WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again
- (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.1. its MiniBrowser stops working. WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again
- (2.41.5-1 => 2.41.6-1) for webkitgtk-6.0. its MiniBrowser still works. 

GPU: GTX 970, Maxwell architecture
nvidia-driver 530

Some more details here:

https://gist.github.com/awfulcooking/70958c36d86b30e6d00d2894bcfa7bb1

[Michael Catanzaro]

*** Bug 259644 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

(In reply to Alberto Garcia from comment #51)
> Hello,
> 
> I have a report from an nVidia user that says that WebKitGTK 2.40.3 works
> fine but after upgrading to 2.41.6 it stops working (but only the GTK3
> builds).
> 
> This is all with Debian unstable on an X11 GNOME session:
> 
> - (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.0. its MiniBrowser stops working.
> WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again
> - (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.1. its MiniBrowser stops working.
> WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again
> - (2.41.5-1 => 2.41.6-1) for webkitgtk-6.0. its MiniBrowser still works. 
> 
> GPU: GTX 970, Maxwell architecture
> nvidia-driver 530
> 
> Some more details here:
> 
> https://gist.github.com/awfulcooking/70958c36d86b30e6d00d2894bcfa7bb1

This user has a different bug that will need to be reported separately.

[Kdwk]

In my case, WebKitGTK 2.40.x works correctly without any issue. It is only with WebKitGTK 2.41.x that I get a blank screen. I can corroborate that web pages seem to be rendered but not shown, and dragging items of the page generate a thumbnail that follows my cursor as expected. Moreover, disabling DMABUF causes the web view to show the correctly rendered page, but the tab hangs quickly after.

[Kdwk]

Copied over from the duplicate bug, my setup is the following:

Tested with: Epiphany Technology Preview/ WebKitGTK 2.41.6; Nvidia RTX 4070 (driver version 535, via Universal Blue Nvidia Image)

No web view is rendered. Blank screen.

Console output:
[kdwk@fedora ~]$ flatpak run org.gnome.Epiphany.Devel 
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1148x893: Permission denied
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1148x893: Permission denied
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1148x893: Permission denied
Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1
[reply] [−] Comment 1

[Thomas Zajic]

Hi, seems like I'm a bit late to the party, but anyways ... I recently reported a bug against liferea (a GTK3 based RSS reader using WebkitGTK as an HTML rendering engine), where the HTML preview frame would appear empty with the newly released webkitgtk-2.42.0, while with webkitgtk-2.40.5 (and all previous webkitgtk versions) the preview frame would be rendered "normally" (ie. as expected).

The devs asked me if I had an Nvidia GPU, and if the problem would disappear if I ran liferea with WEBKIT_DISABLE_COMPOSITING_MODE=1. I do and it did, so they directed me over here. Here's a link to my bug report, which also includes screenshots: https://github.com/lwindolf/liferea/issues/1306

Is this the same bug that is being discussed here? If not, should I open a new bug report, or is there already an existing one that I could follow? Please let me know. Thanks!

[Michael Catanzaro]

(In reply to Thomas Zajic from comment #56)
> Is this the same bug that is being discussed here?

No, because the problem here is specific to GTK 4 and has been around for years. That is, since you didn't have this problem with 2.40, this bug is not your bug.

You're probably hitting either bug #259644 or bug #261874, depending on whether or not you see those KMS DRM_IOCTL_MODE_CREATE_DUMB error messages. Please confirm.

(In reply to Kdwk from comment #55)
> Copied over from the duplicate bug, my setup is the following:
> 
> Tested with: Epiphany Technology Preview/ WebKitGTK 2.41.6; Nvidia RTX 4070
> (driver version 535, via Universal Blue Nvidia Image)
> 
> No web view is rendered. Blank screen.
> 
> Console output:
> [kdwk@fedora ~]$ flatpak run org.gnome.Epiphany.Devel 
> KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 1148x893: Permission denied
> KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 1148x893: Permission denied
> KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 1148x893: Permission denied
> Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1
> [reply] [−] Comment 1

This issue is now tracked in bug #259644.

[Thomas Zajic]

(In reply to Michael Catanzaro from comment #57)
> (In reply to Thomas Zajic from comment #56)
> > Is this the same bug that is being discussed here?
> 
> No, because the problem here is specific to GTK 4 and has been around for
> years. That is, since you didn't have this problem with 2.40, this bug is
> not your bug.
> 
> You're probably hitting either bug #259644 or bug #261874, depending on
> whether or not you see those KMS DRM_IOCTL_MODE_CREATE_DUMB error messages.
> Please confirm.

I'm not using modesetting (KMS), I'm not using flatpak, and I don't see those error messages in any of my logs. So, which of the two "alternative bugs" is "mine"? :-)

Thanks,
Thomas

[Thomas Zajic]

Here's my copy/paste of webkit://gpu, in case that matters. Note that I'm currenty setting "WEBKIT_DISABLE_COMPOSITING_MODE=1" globally from /etc/profile, to work around the rendering bug in liferea.

{
    "Version Information": {
        "WebKit version": "WebKitGTK 2.42.0 (tarball)",
        "Operating system": "Linux 6.1.54 #1 SMP PREEMPT_DYNAMIC Tue Sep 19 15:59:34 CEST 2023 x86_64",
        "Desktop": "GNOME-Flashback:GNOME",
        "Cairo version": "1.16.0 (build) 1.16.0 (runtime)",
        "GStreamer version": "1.22.5 (build) GStreamer 1.22.6 (runtime)",
        "GTK version": "4.12.1 (build) 4.12.2 (runtime)"
    },
    "Display Information": {
        "Type": "X11",
        "Screen geometry": "1920,0 1920x1080",
        "Screen work area": "1920,28 1920x1020",
        "Depth": "24",
        "Bits per color component": "8",
        "DPI": "96"
    },
    "Hardware Acceleration Information": {
        "Policy": "never",
        "WebGL enabled": "Yes"
    }
}

[Georges Basile Stavracas Neto]

I could not reproduce this with NVIDIA RTX 4060, tested with the following configurations:

 * Wayland, Nouveau, WebKitGTK from main
 * Wayland, Nouveau, WebKitGTK 2.42.5
 * Wayland, proprietary driver, WebKitGTK from main
 * Wayland, proprietary driver, WebKitGTK 2.42.5
 * X11, Nouveau, WebKitGTK from main
 * X11, Nouveau, WebKitGTK 2.42.5
 * X11, proprietary driver, WebKitGTK from main
 * X11, proprietary driver, WebKitGTK 2.42.5

I have not tested the GTK3 build.

Will test with an old Kepler card on an ancient laptop I have

[Georges Basile Stavracas Neto]

After Sonny reached out on Mastodon, people reported a variety of problems that were either tracked down to misconfigured systems (e.g. missing NVIDIA GBM, no modesetting, etc), and the cases that did look like interesting cases seemed to be fixed with WebKitGTK 2.42.5.

I think it's reasonable to assume this bug was fixed by the combination of the various refactorings to DMA-BUF handling code in WebKitGTK, and newer NVIDIA cards.

If anyone can reproduce reproduce this with a modern version (2.42+) of WebKitGTK GTK4, please speak up and the issue can be reopened. But please make sure to read https://bugs.webkit.org/show_bug.cgi?id=261874#c32 and see if your issue is not described in that comment.

[Michael Catanzaro]

Hi Craig and Thomas (and Emil if you're still around): if you're still encountering problems with NVIDIA graphics, please report new a bug and leave a comment here linking to the new bug.

[Thomas Zajic]

Hi Michael,

I already hopped over to bug #261874, as the description in #c32 over there matches my setup exactly. The errors I get are:

> [zlatko@disclosure:~]$ liferea
> src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1)
> 
> Failed to create GBM buffer of size 469x191: Invalid argument
> src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1)
> 
>Failed to create GBM buffer of size 469x191: Invalid argument
> src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1)
> 
> Failed to create GBM buffer of size 469x191: Invalid argument
> Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1

Yes, I'm on X11 without modsetting (with NVidia this only works when booting UEFI, which I don't), and "liferea" is a GTK3 application (ie. using libwebkit2gtk-4.0.so), where the current state still seems to be ...

> "There's no workaround for GTK3, we need to figure out why gbm_bo_map is failing and fix it."

... so this bug seems to be the perfect fit. :-)

[Georges Basile Stavracas Neto]

This bug is for GTK4, Liferea is GTK3. That's a separate issue that should not be marked as a blocker for https://bugs.webkit.org/show_bug.cgi?id=210100

[Craig]

(In reply to Michael Catanzaro from comment #62)
> Hi Craig and Thomas (and Emil if you're still around): if you're still
> encountering problems with NVIDIA graphics, please report new a bug and
> leave a comment here linking to the new bug.

My problem was on legacy nvidia driver, and newer versions wouldn't even start.  But I now know a workaround (GSK_RENDERER=cairo) and don't expect there will be a fix for my old driver anyway.
https://gitlab.gnome.org/GNOME/gtk/-/issues/5858