Bug 1663273 Comment 72 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Thanks Robert. I did some experiments mainly with the NVIDIA closed source drivers and also EGL drivers and think the X11 alpha/non-alpha visual does mean much in this case. Bug 1663003 / https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376 is related here. The GL rendering pipeline uses its own setup and the final presentation to X11 is another think.

The setup at nsWindow::Create() has two purposes:

- If we can match GL visual and X11 visual we can paint transparent windows by GL. That's recently fails on EGL (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376) where we need to use GLX for it (the isEGL hack:
https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/widget/gtk/nsWindow.cpp#4377)
If we fail here the GL rendered windows are not transparent but that's all.

- Match GL visual and X11 visual on NVIDIA/GLX. NVIDIA proprietary drivers needs that, otherwise we can't create GL Context and WebRender/GLCompositor init fails.

So we really can always use alpha visual for Gtk widgets with WebRender and in case of non-compositing DE the alpha is ignored, as well as when we fails to match X11/EGL visuals. The IsAccelerated condition was here for old GL compositor, I thin we can drop it now and use WR only. Another question is how WR-SW is handled here.
Thanks Robert. I did some experiments mainly with the NVIDIA closed source drivers and also EGL drivers and think the X11 alpha/non-alpha visual does mean much in this case. Bug 1663003 / https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376 is related here. The GL rendering pipeline uses its own setup and the final presentation to X11 is another thing.

The setup at nsWindow::Create() has two purposes:

- If we can match GL visual and X11 visual we can paint transparent windows by GL. That's recently fails on EGL (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376) where we need to use GLX for it (the isEGL hack:
https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/widget/gtk/nsWindow.cpp#4377)
If we fail here the GL rendered windows are not transparent but that's all.

- Match GL visual and X11 visual on NVIDIA/GLX. NVIDIA proprietary drivers needs that, otherwise we can't create GL Context and WebRender/GLCompositor init fails.

So we really can always use alpha visual for Gtk widgets with WebRender and in case of non-compositing DE the alpha is ignored, as well as when we fails to match X11/EGL visuals. The IsAccelerated condition was here for old GL compositor, I thin we can drop it now and use WR only. Another question is how WR-SW is handled here.
Thanks Robert. I did some experiments mainly with the NVIDIA closed source drivers and also EGL drivers and think the X11 alpha/non-alpha visual does mean much in this case. Bug 1663003 / https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376 is related here. The GL rendering pipeline uses its own setup and the final presentation to X11 is another thing.

The setup at nsWindow::Create() has two purposes:

- If we can match GL visual and X11 visual we can paint transparent windows by GL. That recently fails on EGL (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376) where we need to use GLX for it (the isEGL hack:
https://searchfox.org/mozilla-central/rev/2efcda6dc74c63863fd8f04a6d9d7ac6b09c7eca/widget/gtk/nsWindow.cpp#4377)
If we fail here the GL rendered windows are not transparent but that's all.

- Match GL visual and X11 visual on NVIDIA/GLX. NVIDIA proprietary drivers needs that, otherwise we can't create GL Context and WebRender/GLCompositor init fails.

So we really can always use alpha visual for Gtk widgets with WebRender and in case of non-compositing DE the alpha is ignored, as well as when we fails to match X11/EGL visuals. The IsAccelerated condition was here for old GL compositor, I thin we can drop it now and use WR only. Another question is how WR-SW is handled here.

Back to Bug 1663273 Comment 72