[Mesa-dev] [Bug 99237] Impossible to create transparent X11/EGL windows while respecting EGL_NATIVE_VISUAL_ID

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99237

            Bug ID: 99237
           Summary: Impossible to create transparent X11/EGL windows while
                    respecting EGL_NATIVE_VISUAL_ID
           Product: Mesa
           Version: 13.0
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: EGL
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: nfxjfg at gmail.com
        QA Contact: mesa-dev at lists.freedesktop.org

eglGetConfigs() never lists EGLConfigs that point to RGBA X visuals in their
EGL_NATIVE_VISUAL_ID attribute. If you create an EGL context and X11 window the
"proper" way, i.e. use eglGetConfigs() or eglChooseConfig() and then create a
window with the visual noted in the chosen EGLConfig's  EGL_NATIVE_VISUAL_ID
attribute, the resulting window's GL-rendered contents will never be
alpha-blended by the compositor.

nVidia's EGL implementation on the other hand does list EGLConfigs with RGBA
visuals. (They have two almost identical EGLConfigs following each other: first
one with a RGB X visual, then with a RGBA one. All fields except EGL_CONFIG_ID
and EGL_NATIVE_VISUAL_ID are the same.)

I think that Mesa should do it the same way, and that not doing this is a bug
and/or a missing feature that should be added.

Seems like this is done explicitly in dri2_x11_add_configs_for_visuals:
https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_x11.c#n752

First, it allows only 1 config/visual per color class. It really should add two
visuals at least for TrueColor visuals (a RGB and then a RGBA one). Second it
has some code that explicitly excludes RGBA X visuals, with comments about how
applications don't want alpha-composited windows. I'm not completely aware why
this can't just be done via the EGL_ALPHA_SIZE attribute (if it's 0, select a
RGB-only config), but maybe there are reasons. (Wayland apparently does not
care about those reasons, and if you get a RGBA config, your window is always
alpha-composited, but I didn't double-check this.) nVidia/EGL and GLX avoid
such problems by always listing a config backed by a RGB X visual first.

You could also argue that the API user should just use a RGBA visual when
creating the X window, either by completely ignoring the chosen EGLConfig's
EGL_NATIVE_VISUAL_ID attribute, or by attempting to select a "compatible" one.
However, not all drivers allow using a different X visual (even if it's
compatible). The nVidia driver is one such driver. The EGL spec also explicitly
states that it's implementation specific whether another underlying pixel
format can be used (and mention different X visual IDs as example).

I'm sure application developers should be spared from trying to support both
Mesa and nVidia in the hard way by having to implement both methods. While I'm
personally less than enchanted for needing platform-specific code in the EGL
config selection just to get X11 transparency, nVidia's idea seems to be the
best way to implement it. It's similar to how GLX behaves,
backwards-compatible, and the application does not need to try to use different
visuals for window creation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161231/beeb19b2/attachment.html>