Closed Bug 1731125 Opened 3 years ago Closed 3 years ago

MOZ_X11_EGL/Nvidia: Black border around Pocket or webextension popup

Categories

(Core :: Graphics: WebRender, defect)

Product:
Core
Component:
Graphics: WebRender
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
94 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- disabled
firefox-esr91 --- disabled
firefox92 --- disabled
firefox93 --- disabled
firefox94 --- fixed

People

(Reporter: jan, Assigned: rmader)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

Bug 1731125 [Linux/EGL] Render popups by SW-WR on X11/EGL due to missing transparency, r?rmader
48 bytes, text/x-phabricator-request
Details | Review
2021-10-02 19-05-56.mp4
5.49 MB, video/mp4
Details
visualtest.c
32.73 KB, text/plain
Details

Gnome X11, GTX 1060, Nvidia driver 470

Click on the Pocket icon.
mozregression --launch 2021-09-16
(MOZ_X11_EGL=1 mozregression --launch 2021-09-16 --pref gfx.webrender.all:true)

May or may not be helpful:
https://github.com/qt/qtbase/commit/0712b4ff7139b5c2cc96fd40ea7bb77a9bb8fd1c
https://github.com/qt/qtbase/blob/dev/src/gui/opengl/platform/egl/qxlibeglintegration.cpp

https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/xcb/gl_integrations/xcb_egl/qxcbeglwindow.cpp
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_platform_x11.txt

  • It uses XGetVisualInfo for EGL. Firefox uses it only for GLX.
  • It uses XCreateColormap for EGL. Firefox uses it only for GLX in glxtest or in gfxXlibSurface.cpp.

https://developer.nvidia.com/blog/egl-eye-opengl-visualization-without-x-server/
https://download.nvidia.com/XFree86/Linux-x86_64/304.137/README/xcompositeextension.html

Overview:

Does this happen with SW-WR as well? If not, then bug 1479135 and bug 1710855 are likely related and we likely need to adapt https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#931-936 for this case.

Yes, all panels are fine with SW-WR:
mozregression --launch 2021-09-17 --pref gfx.webrender.software:true

HW WR:
Black borders do not show up for Protections, Site Information, Bookmark and Main menu panels. Autoscroll icon is also fine.
Black borders only show up for Pocket and uBlock Origin.

(In reply to Robert Mader [:rmader] from comment #3)
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12819
Back then Nvidia was apparently against the Mesa commit you are trying to revert:
https://bugs.freedesktop.org/show_bug.cgi?id=67676#c17
https://lists.x.org/archives/mesa-dev/2015-April/082140.html

We always have and will continue to support alpha blending of ARGB visuals/configs.

Wouldn't that mean that if your MR was accepted, Mesa would behave like Nvidia again?
Can you reproduce this bug if you patch your Mesa with your MR and switch to GLContextEGL::FindVisual?
If yes, could comment 0 help you to fix GLContextEGL::FindVisual?
If yes, wouldn't that be the strongest pro-argument for merging your MR we could provide?

See Also: → 1677314

(In reply to Darkspirit from comment #5)

Wouldn't that mean that if your MR was accepted, Mesa would behave like Nvidia again?

Yes, I think so. I'm still trying to get feedback on all of that, kinda frustrating :(

Assignee: nobody → robert.mader
Status: NEW → ASSIGNED

I have the same issue, but it's only around popups launched by extensions. For example - if the overflow menu is opened by hand, the popup looks fine, but if it gets popped open by an extensions - like, for example 1password, then the black border is present (looks like transparency is missing). I posted some images on Twitter - https://twitter.com/jonrandy/status/1442062264505233414

Changing severity to S2 because of pretty ugly and visible side effects, no workaround or settings mitigation available right now.

Severity: -- → S2

Workaround: gfx.x11-egl.force-disabled=true (bug 1732002)

At the moment, you can only choose which bugs you want to encounter: GLX vs. EGL
MOZ_X11_EGL (which also makes x11 glitches less likely: bug 1678804) fixes an actually severe bug:
Multiple windows with WebRender/GLX can be considered slightly broken on Nvidia (bug 1716049) and horribly broken for some non-Gnome Mesa users (bug 1732365). Only alternative to EGL would be uplifting a barely testable change to legacy GLX: bug 1732365 comment 29

A bug like this has been the default on Linux desktops with disabled compositor for many years (bug 1479135). It was fixed by enforcing software WebRender for those widgets on uncomposited desktops. Options for this bug:
a) uplift a fixed GLContextEGL::FindVisual
b) uplift SW WR enforcement for affected widgets on non-Mesa X11 (comment 3)
c) uplift bug 1732002
d) wontfix for 94, but have at least bug 1716049 fixed by using EGL.

Workaround: gfx.x11-egl.force-disabled=true (bug 1732002)

The exact wording for S2 is "a satisfactory workaround doesn’t exist" and from your comment I think that is the case because the above causes arguably worse problems?

(a) or (b) seem like good options, but it's not like I know what I'm talking about here :-P

I think we should just land bug 1732002 - as long as bug 1731172 is not solved, EGL should not ship to stable IMO.

See Also: → 1732002

For bug 1731172 Firefox should add to the release notes that package maintainers must set the required Nvidia driver flag according to the Nvidia manual.
The Ubuntu Firefox 92 snap package already ships pre-Nightly MOZ_ENABLE_WAYLAND which means EGL. The snap is already affected by bug 1731172. That's why we must ask all distributions anyway to package the Nvidia driver properly: bug 1731172 comment 18

Disabling EGL/Nvidia (bug 1732002) would require us to fix GLX/Nvidia (bug 1732365 comment 29).

(In reply to Darkspirit from comment #12)

For bug 1731172 Firefox should add to the release notes that package maintainers must set the required Nvidia driver flag according to the Nvidia manual.

I don't think that's a feasible solution. The feature does not appear to be fully ready and distributions will not suddenly enable it just because Firefox says they have to. Concerning MOZ_ENABLE_WAYLAND: I don't think that matters - Ubuntu doesn't enable Wayland session by default on Nvidia.

would require us to fix GLX/Nvidia

It's already broken in stable - if we don't fix it in 94, that's not the end of the world.

As a workaround here we can fall back to SW rendering of all popups on X11/EGL. I don't think it matter much to have HW accelerated popup rendering :)

Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/ec6135a35df9 [Linux/EGL] Render popups by SW-WR on X11/EGL due to missing transparency, r=rmader

https://hg.mozilla.org/mozilla-central/rev/ec6135a35df9

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox94: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch
Attached video 2021-10-02 19-05-56.mp4 —

Screencast: I managed to get a transparent EGL window on Nvidia.
At the moment I just hardcode framebuffer_config_attrib_list[] = { EGL_CONFIG_ID, 0x008, etc., but the conclusion seems to be:
If eglGetConfigAttrib EGL_NATIVE_VISUAL_ID (0x82) is what gdk_x11_visual_get_xvisual(gdk_screen_get_rgba_visual) gave us (0x82), then it's the correct Nvidia egl framebuffer config (0x8).

First I tried to set the visual in realize(), but then eglCreateWindowSurface failed with EGL_BAD_MATCH.
gtk_widget_set_visual() must be called with the window_widget_ptr from gtk_window_new(),
not with the widget_ptr inside the g_signal_connect realize function.

I'll attach the testcase after cleaning it up a bit.

Gnome Xwayland (GDK_BACKEND=x11): On Mesa it works slightly different, but it works as well.
$ eglinfo shows many mesa egl framebuffer configs, but visid is always either 0x24TC or 0x25DC. If we want TrueColor, then 0x24 is the only xvisual that all of mesa's egl framebuffer configs "want", but that one is not transparent.

0x01 32 0 8 8 8 8 0 0 0 0 0x24TC a y y y win,pb,pix

But we can ignore it!
Just set the xvisual 0x505 on the widget which we can get from gdk_screen_get_rgba_visual and transparent EGL windows work on Mesa as well:

GdkScreen *gdk_screen_ptr = gtk_widget_get_screen(widget_ptr);
GdkVisual *gdk_visual_ptr = gdk_screen_get_rgba_visual(gdk_screen_ptr);
//Visual *x_visual_ptr = gdk_x11_visual_get_xvisual(gdk_visual_ptr);
//uint32_t x_visual_id = x_visual_ptr->visualid;
gtk_widget_set_visual(widget_ptr, gdk_visual_ptr);

I've just noticed that the main windows on Firefox Nightly are also exhibiting the same behaviour - the rounded top corners of the windows on the normal Ubuntu theme have a black background - https://imgur.com/a/4IIUl7X

Yes, it's in the table in bug 1733094 comment 14.

Attached file visualtest.c —

(Screencast in comment 19.)
Could this work for Firefox as well?

  1. Ask GTK for an opaque or rgba GdkVisual and set it on the GtkWidget.
    (I assume this wasn't possible in the past when WebRender required depth because gdk_screen_get_rgba_visual and gdk_screen_get_system_visual select a GdkVisual with 32 (transparent) or 24 (opaque) "X visual depth", but with 0 depth.
    "EGL_BAD_MATCH is generated if the pixel format of native_window does not correspond to the format, type, and size of the color buffers required by config.")
  2. Get X Visual ID of the GdkVisual.
  3. Get EGL framebuffer configs that meet our criteria.
  4. Select the fb config that has the same X Visual id as our widget. (Nvidia: The first fb config wants an opaque x visual, the second one wants a transparent x visual.)
  5. Fallback for Mesa: If none matched, select the first EGL framebuffer config.
Flags: needinfo?(stransky)
Attachment #9244123 - Attachment mime type: text/x-csrc → text/plain

(In reply to Darkspirit from comment #23)

Created attachment 9244123 [details]
visualtest.c

(Screencast in comment 19.)
Could this work for Firefox as well?

  1. Ask GTK for an opaque or rgba GdkVisual and set it on the GtkWidget.
    (I assume this wasn't possible in the past when WebRender required depth because gdk_screen_get_rgba_visual and gdk_screen_is_composited select a GdkVisual with 32 (transparent) or 24 (opaque) "X visual depth", but with 0 depth.
    "EGL_BAD_MATCH is generated if the pixel format of native_window does not correspond to the format, type, and size of the color buffers required by config.")
  2. Get X Visual ID of the GdkVisual.
  3. Get EGL framebuffer configs that meet our criteria.
  4. Select the fb config that has the same X Visual id as our widget. (Nvidia: The first fb config wants an opaque x visual, the second one wants a transparent x visual.)
  5. Fallback for Mesa: If none matched, select the first EGL framebuffer config.

Hello Jan, yes, I think that can work as we don't need the z buffer any more.

Flags: needinfo?(stransky)
See Also: → 1735909
Regressions: 1741956
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: