Bug 67676

Sad sad sad :(

EGL provides no mechanism by which the application can request a transparent window. We need to define an EGL extension for that, tentatively named EGL_MESA_transparent_alpha.

Without such an extension, Mesa needs to give transparent windows to everyone, or transparent windows to no one.

The extension is on my todo list, but it's nearer to the bottom than the top of the list. If you'd like to pick the task up, I can explain how to proceed.

Colleagues are hitting this bug, so I started wondering...

EGLConfigs carry the X11 Visual id, right? Would it not be possible to add more EGLConfigs, otherwise equivalent to the current ARGB8888 configs, but having the magic alpha visual? These would be sorted after the opaque ARGB8888 configs, so they hopefully would not be picked up by default. Then apps, who really want the magic alpha, could manually look for the right native visual id in the configs to get it.

It would be an X11-only solution/hack, but is there something fundamentally wrong with it?

I don't think there is anything fundamentally wrong with your proposed X11-specific hack.

But, I think it's unwise to implement the hack. The amount of code and hackery needed---the implementation code in Mesa as well as the client code in the X11 app to use Mesa's hack---I predict will be more convoluted and fragile than the analogous code for a new extension, EGL_MESA_transparent_alpha, that adds a new value for attribute EGL_TRANSPARENT_TYPE. And, unlike an X11-specific hack, this extension would also apply to Wayland.

(In reply to comment #1)
> Without such an extension, Mesa needs to give transparent windows to
> everyone, or transparent windows to no one.

Maybe I'm just being dense here; surely there's something I'm missing. The ALPHA_SIZE test in ChooseConfig checks for the lowest value that's greater than or equal to what was specified, and the default is zero. So people using ChooseConfig will get non-alpha RGB configs preferred, unless they either hunt for something using a 32bpp visual, or explicitly requested alpha size.

If they've requested alpha explicitly, you can be fairly sure they're going to want to use it ...

Can this at least be hidden behind an EGL_CONFORMANT_IF_NOT_PERHAPS_QUITE_AS_PERFORMANT variable or something? Removing the possibility to ever render destination alpha is pretty vicious, and breaks more than you'd expect (think UIs, not games).

Is the idea behind this hack just to improve performance for people naïvely looking to match an EGL config to the X11 visual it's suggested they use?

Daniel: the problem is that normal apps use the alpha, but they don't fill it with values that should be used to blend window contents over other windows.  So you must not return the rgba visual when people aren't really looking for the rgba visual.  Nothing in the change was about performance.

We should certainly be exposing EGLConfigs that match up to the rgba visual, though, so you can find it when you try.

Created attachment 93777 [details] [review]
Proposed patch


egl_dri2: Allow both 24 and 32 bit X visuals for RGBA configs
    
When using RGBA EGLConfigs allow both RGB and RGBA X visuals, such that
application can decide whether they want to use RGBA (and have the
compositor blend their windows).
    
On my system with this change EGLConfigs with a 24 bit visual comes up
first, as such applications blindly picking the first EGLConfig will
still get an RGB X visual.


Note that with this patch dri2_match_config only considers EGLConfigs to match iff their NativeVisualID also matches. Which is imho correct for X11, but i'm not sure if this is a valid thing to compare on other display systems.

Created attachment 94274 [details] [review]
Updated patch

From comments by daniels, check for EGL_DONT_CARE in the matching criteria for consistency

Created attachment 111864 [details]
EGL_MESA_transparent_alpha draft

Here is my initial draft for this extension. It's already been fixed after a round of comments from Daniel and Pekka.

Anywhere else I should sent it for comments?

Eric, Chad, any thoughts on the above?

Jonny, did you have the Mesa implementation as well?

The proposed extension looks like the right approach to me.

Regarding issue #1, I weakly prefer that it be illegal to specify EGL_TRANSPARENT_ALPHA for non-window surfaces. I like to emit errors when the user asks for the impossible.

Errors I found in the draft:
  - It should be a EGL display extension, not an EGL client extension.
  - The new symbols must be suffixed with MESA.

Created attachment 113529 [details]
EGL_MESA_transparent_alpha draft 2

(In reply to Chad Versace from comment #10)
> The proposed extension looks like the right approach to me.
> 
> Regarding issue #1, I weakly prefer that it be illegal to specify
> EGL_TRANSPARENT_ALPHA for non-window surfaces. I like to emit errors when
> the user asks for the impossible.
> 
> Errors I found in the draft:
>   - It should be a EGL display extension, not an EGL client extension.
>   - The new symbols must be suffixed with MESA.

Thanks for your comments, I've updated the draft and attached it here. What do you think?

Created attachment 113561 [details]
third draft

Here is version three with a few typos fixed from version two and a note added about pre-multiplied alpha.

Created attachment 113563 [details]
version three

Apologies for the noise, fixed a few extra problems.

n reply to Jonny Lamb from comment #13)
> Created attachment 113563 [details]
> version three

Comments:

- Good call on specifying pre-multiplied alpha.

- I think you should remove the paragraph

    To determine if the EGL implementation supports this extension, clients
    should query the EGL_EXTENSIONS string of the current active display.

  because that's the normal way of querying extensions and needs no
  explanation. I found that paragraph confusing because it made me ask "Why is
  the extension telling me this? Is there some magic in this extension that I've
  failed to see that warrants this explanation?". The platform extension
  specification that you used as a template explicitly describes how to perform
  the extension query because its query mechanism differs from 95% of existing
  EGL extensions.

- You should remove the "New Behavior" section. Normally, the fine details of
  an extension specification are defined in the "Additions to the EGL x.y
  specification" section as a diff against the EGL x.y spec. This extension is no
  different. A few, special extensions, though, define behavior that should *not*
  be added to the EGL spec, such as the platform extensions. That's what the "New
  Behavior" section should be used for, and this alpha extension defines no such
  "outside-of-the-spec" behavior.

- The paragraph

    To obtain an EGL window surface with a meaningful alpha channel, use an
    EGLConfig with EGL_TRANSPARENT_TYPE set to EGL_TRANSPARENT_ALPHA_MESA.

  is still valuable, despite belonging in the "New Behavior" section. The
  proper location for it is the "Overview" section.

- Regarding issue #1:

    RESOLUTION: Yes. Non-window surfaces created with
    EGL_TRANSPARENT_TYPE set to EGL_TRANSPARENT_ALPHA_MESA will
    generate an error.

  What error does it generate? If we refer to this paragraph of Section 3.5.1 as precedent,

    If config does not support rendering to windows (the EGL_SURFACE_TYPE
    attribute does not contain EGL_WINDOW_BIT ), an EGL_BAD_MATCH error is
    generated.

  then the resolution text can be clarified as:

    RESOLUTION: Attempting to create a non-window surface with a config in
    which EGL_TRANSPARENT_TYPE is EGL_TRANSPARENT_ALPHA_MESA, then an
    EGL_BAD_MATCH error is generated.


- Other than the above (mostly sylistic) issues, the extension looks good to
  me.  Thanks for writing it! When you submit to mesa-dev, please CC me.

Created attachment 113752 [details]
version four

(In reply to Chad Versace from comment #14)
> - Good call on specifying pre-multiplied alpha.

Thanks to Pekka for suggesting that. :-)

> - I think you should remove the paragraph
> 
>     To determine if the EGL implementation supports this extension, clients
>     should query the EGL_EXTENSIONS string of the current active display.
> 
>   because that's the normal way of querying extensions and needs no
>   explanation. I found that paragraph confusing because it made me ask "Why
> is
>   the extension telling me this? Is there some magic in this extension that
> I've
>   failed to see that warrants this explanation?". The platform extension
>   specification that you used as a template explicitly describes how to
> perform
>   the extension query because its query mechanism differs from 95% of
> existing
>   EGL extensions.

Fair. It was included because it was previously a client extension but now I agree it's not necessary.

> - You should remove the "New Behavior" section. Normally, the fine details of
>   an extension specification are defined in the "Additions to the EGL x.y
>   specification" section as a diff against the EGL x.y spec. This extension
> is no
>   different. A few, special extensions, though, define behavior that should
> *not*
>   be added to the EGL spec, such as the platform extensions. That's what the
> "New
>   Behavior" section should be used for, and this alpha extension defines no
> such
>   "outside-of-the-spec" behavior.

OK, removed.

> - The paragraph
> 
>     To obtain an EGL window surface with a meaningful alpha channel, use an
>     EGLConfig with EGL_TRANSPARENT_TYPE set to EGL_TRANSPARENT_ALPHA_MESA.
> 
>   is still valuable, despite belonging in the "New Behavior" section. The
>   proper location for it is the "Overview" section.

Right.

> - Regarding issue #1:
> 
>     RESOLUTION: Yes. Non-window surfaces created with
>     EGL_TRANSPARENT_TYPE set to EGL_TRANSPARENT_ALPHA_MESA will
>     generate an error.
> 
>   What error does it generate? If we refer to this paragraph of Section
> 3.5.1 as precedent,
> 
>     If config does not support rendering to windows (the EGL_SURFACE_TYPE
>     attribute does not contain EGL_WINDOW_BIT ), an EGL_BAD_MATCH error is
>     generated.
> 
>   then the resolution text can be clarified as:
> 
>     RESOLUTION: Attempting to create a non-window surface with a config in
>     which EGL_TRANSPARENT_TYPE is EGL_TRANSPARENT_ALPHA_MESA, then an
>     EGL_BAD_MATCH error is generated.

Ah yes I now notice I also answered a "this or this?" question with "yes"! Fixed.

> - Other than the above (mostly sylistic) issues, the extension looks good to
>   me.  Thanks for writing it! When you submit to mesa-dev, please CC me.

Thanks very much for your comments, they've been very helpful.

I've attached the updated extension.

http://lists.freedesktop.org/archives/mesa-dev/2015-February/077586.html

Extension and implementation posted to the list.

Adding James Jones to CC, because he has expressed disagreement on the proposed solution:
http://lists.x.org/archives/mesa-dev/2015-April/082140.html

Hi all,

Based on the feedback so far, plus the fact that the i965 (suspecting that others do as well) module allows/exposes relevant format(s) should we mark this as won't fix. Or perhaps there is still some interest in the proposed extension ?

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

Of course there should be a solution for this. The current situation would require awful hacks to make it work with Mesa (or not work on nVidia). (See my comments in bug #99237.)

If I read the nVidia person's reply correctly, the complaint is that EGL_TRANSPARENT_TYPE is for color-keying only. Not sure why that blocked progress for years.

Sounds to me like two things should be done:
1. For each EGLConfig add a second EGLConfig with the equivalent RGBA visual if available. (This is what nVidia does on EGL, and what both nVidia and Mesa do on GLX.)
2. Optionally, specify a new extension that adds a new config attribute that specifies whether an EGLConfig is backed by a visual that enables alpha compositing of the window (say, EGL_ALPHA_WINDOW, which could have the values EGL_TRUE or EGL_FALSE).

(In reply to Daniel Stone from comment #4)

> Can this at least be hidden behind an
> EGL_CONFORMANT_IF_NOT_PERHAPS_QUITE_AS_PERFORMANT variable or something?
> Removing the possibility to ever render destination alpha is pretty vicious,
> and breaks more than you'd expect (think UIs, not games).

This category of config sorting bug is why GLX has visual select groups:

https://www.khronos.org/registry/OpenGL/extensions/SGIX/GLX_SGIX_visual_select_group.txt

https://cgit.freedesktop.org/xorg/xserver/commit/glx/glxscreens.c?id=ea483af99a6351323afe00a0b630cd63310efdb1

Personally I'd just implement the same thing internally to EGL and put the alpha-ful configs in a less-preferred select group. You'll still get alpha if you ask for it, but you won't if you don't.

Note the NVIDIA proprietary driver maps alpha -> "I want transparency!" in both GLX and EGL, and I warned Mesa when this change was made it would break compatibility with our driver and apps that rely on it.  So I'd be in favor of restoring that behavior in Mesa as well.

Created attachment 144608 [details] [review]
A patch that fixes transparency.

Created attachment 144609 [details] [review]
A patch that puts RGBA visuals in the second config selection group. (Depends on first patch)

Created attachment 144610 [details]
EGL_MESA_config_select_group

I've implemented the solution suggested by Adam Jackson:

(In reply to Adam Jackson from comment #21)
>
> This category of config sorting bug is why GLX has visual select groups:
> 
> https://www.khronos.org/registry/OpenGL/extensions/SGIX/
> GLX_SGIX_visual_select_group.txt
> 
> https://cgit.freedesktop.org/xorg/xserver/commit/glx/glxscreens.
> c?id=ea483af99a6351323afe00a0b630cd63310efdb1
> 
> Personally I'd just implement the same thing internally to EGL and put the
> alpha-ful configs in a less-preferred select group. You'll still get alpha
> if you ask for it, but you won't if you don't.

I didn't understand Xorg's code, so I wrote a second patch that puts it in the second config selection group from the mesa side. I'm not sure if that's an acceptable solution, so here we are.

Please forgive me, for I've never written an extension before and I'm sure there's some* errors to it, ect ect

*Probably the understatement of the century.

(In reply to Hal Gentz from comment #26)
> I've implemented the solution suggested by Adam Jackson:
> 
> (In reply to Adam Jackson from comment #21)
> >
> > This category of config sorting bug is why GLX has visual select groups:
> > 
> > https://www.khronos.org/registry/OpenGL/extensions/SGIX/
> > GLX_SGIX_visual_select_group.txt
> > 
> > https://cgit.freedesktop.org/xorg/xserver/commit/glx/glxscreens.
> > c?id=ea483af99a6351323afe00a0b630cd63310efdb1
> > 
> > Personally I'd just implement the same thing internally to EGL and put the
> > alpha-ful configs in a less-preferred select group. You'll still get alpha
> > if you ask for it, but you won't if you don't.
> 
> I didn't understand Xorg's code, so I wrote a second patch that puts it in
> the second config selection group from the mesa side. I'm not sure if that's
> an acceptable solution, so here we are.

This is mostly fine.

> Please forgive me, for I've never written an extension before and I'm sure
> there's some* errors to it, ect ect

Some spec review:

>    This extension provides a mechanism to lower the config selection priority 
>    of the configs returned by eglChooseConfig. A new config attribute is
>    introduced, providing a way for servers to group configs into different
>    config selection categories.

EGL doesn't require a "server" in the X11 sense. It's probably best to
phrase this as "a way for EGL to" or "a way for the implementation to".

>                                  The config selection priorities of all the
>    configs in one category may be higher or lower than the ones in other
>    categories.  The config selection priorities in one category follow the
>    rules of eglChooseConfig.  The new attribute is invisible to users so it
>    can't be queried by eglGetConfigAttrib.

I only sort of understand why the GLX extension decided to hide this extension
from queries, I'm not sure it's all that important to insist on it for EGL.
Particularly since without it, it's difficult to discover why you're getting
an unexpected config.

>    Accepted as the value of the EGLConfig attribute EGL_TRANSPARENT_TYPE:

I don't think you mean this. You don't want to allow filtering configs based
on the select group number, and the select group number is not a transparency
type.

>        EGL_CONFIG_SELECT_GROUP_MESA                0x31D9

Annoyingly, 0x31D9-0x31DB are in use by EGL_WL_bind_wayland_display, but not
noted as such in egl.xml. 0x31DC appears to be the lowest unused enum.

>    "The attribute EGL_CONFIG_SELECT_GROUP_MESA is used for communication
>    between servers and the EGL client. It is not accepted by the <attrib_list>
>    parameter of eglChooseConfig, nor is it accepted as the <attribuite> in
>    eglGetConfigAtrrib."

Again, EGL doesn't necessarily require a client/server split. I might say something more like: "The attribute EGL_CONFIG_SELECT_GROUP_MESA is used by the EGL to override the default sorting rules, by collecting configurations into groups." And if you choose to allow querying the select group, s/nor is it/but it is/.

Also, "attribuite" should be "attribute".

Nice that there's some movement.

I have no idea what the patch does. What does it mean for clients?

First of all, thank you for taking time to look at this!

> Some spec review:
> 
> >    This extension provides a mechanism to lower the config selection priority 
> >    of the configs returned by eglChooseConfig. A new config attribute is
> >    introduced, providing a way for servers to group configs into different
> >    config selection categories.
> 
> EGL doesn't require a "server" in the X11 sense. It's probably best to 
> phrase this as "a way for EGL to" or "a way for the implementation to".

My bad, this was sort of cargo-culted from the GLX extension, without any regard
to whether or not it was still applicable.

> >                                  The config selection priorities of all the
> >    configs in one category may be higher or lower than the ones in other
> >    categories.  The config selection priorities in one category follow the
> >    rules of eglChooseConfig.  The new attribute is invisible to users so it
> >    can't be queried by eglGetConfigAttrib.
> 
> I only sort of understand why the GLX extension decided to hide this
> extension
> from queries, I'm not sure it's all that important to insist on it for EGL.
> Particularly since without it, it's difficult to discover why you're getting
> an unexpected config.
> 

Fair enough, I presumed there was a reason behind it that I was simply missing
out on, and just cargo-culted this as well. 

> >    Accepted as the value of the EGLConfig attribute EGL_TRANSPARENT_TYPE:
> 
> I don't think you mean this. You don't want to allow filtering configs based
> on the select group number, and the select group number is not a transparency
> type.
> 
> >        EGL_CONFIG_SELECT_GROUP_MESA                0x31D9

My bad, I've replaced this with "Accepted as a new EGLConfig attribute:", as
that is actually correct to my knowledge. It was just another cargo-culted
phrase.

> Annoyingly, 0x31D9-0x31DB are in use by EGL_WL_bind_wayland_display, but not
> noted as such in egl.xml. 0x31DC appears to be the lowest unused enum.

I was not aware. Thank you!

> >    "The attribute EGL_CONFIG_SELECT_GROUP_MESA is used for communication
> >    between servers and the EGL client. It is not accepted by the <attrib_list>
> >    parameter of eglChooseConfig, nor is it accepted as the <attribuite> in
> >    eglGetConfigAtrrib."
> 
> Again, EGL doesn't necessarily require a client/server split. I might say
> something more like: "The attribute EGL_CONFIG_SELECT_GROUP_MESA is used by
> the EGL to override the default sorting rules, by collecting configurations
> into groups." And if you choose to allow querying the select group, s/nor is
> it/but it is/.
> 
> Also, "attribuite" should be "attribute".

Yeah, I was not aware that EGL didn't need a client/server split. I assumed it
would be similar to GLX, and just kept it basically as is. Thanks.

(In reply to nfxjfg from comment #28)
> Nice that there's some movement.
> 
> I have no idea what the patch does. What does it mean for clients?

EGLConfigs with alpha-blending will be placed closer to the bottom of the list.
Clients that want those configs will just have to iterate over the whole list
looking for one which supports alpha-blending. `XRenderFindVisualFormat` is your
friend for this task. Clients that don't want alpha-blending can continue to
just select the first config that pops up.

Created attachment 144758 [details]
EGL_MESA_config_select_group v2

I'm going to update my patch to use `0x31DC` on the weekend. I plan to also check that passing EGL_CONFIG_SELECT_GROUP_MESA to eglGetConfigAtrrib doesn't do anything silly.

It took some fiddling, but I did get it to work, and as you can see, it is sorting everything properly: https://github.com/rust-windowing/glutin/issues/1191#issuecomment-512015144

I've updated the PR on gitlab: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1185

bz migration script doesn't like this bug, but there's a partial import of this issue here:

https://gitlab.freedesktop.org/mesa/mesa/issues/149

Please follow up there.