[Mesa-dev] [PATCH 2/2] egl: implement EGL_MESA_transparent_alpha for x11 and wayland

[James Jones]

On 04/17/2015 04:08 PM, James Jones wrote:
> On 03/03/2015 11:05 AM, Daniel Stone wrote:
>> Hi,
>>
>> On 3 March 2015 at 18:56, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> On Tue, Mar 3, 2015 at 10:07 AM, Chad Versace <chad.versace at intel.com>
>>> wrote:
>>>> On 02/23/2015 06:32 AM, Jonny Lamb wrote:
>>>>> +   static const EGLint argb_attrs[] = {
>>>>> +       EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_ALPHA_MESA,
>>>>> +       EGL_NONE
>>>>> +   };
>>>>>
>>>>
>>>> I tested this patch with X11 and Mesa, and it works as advertised.
>>>> BUT...
>>>>
>>>> Pre-patch, Wayland applications who requested an EGLConfig with alpha
>>>> received one. The EGLSurface had compositor-transparent alpha, which
>>>> the application may not have expected. But the alpha configs *were*
>>>> available.
>>>>
>>>> Post-patch, existing Wayland applications that request an EGLConfig
>>>> with
>>>> alpha will no longer receive one, because the existing applications
>>>> do not yet know about EGL_TRANSPARENT_ALPHA_MESA.
>>>>
>>>> I believe a correct solution is to continue create EGLConfigs
>>>> with EGL_ALPHA and without EGL_TRANSPARENT_TYPE, as Mesa does today,
>>>> but tell the compositor to ignore the alpha channel. The alpha channel
>>>> will be used for client-side alpha-blending but not for compositing.
>>>> Jason says that should be possible by telling the compositor that
>>>> the buffer format is WL_DRM_FORMAT_XRGB8888. And in addition to the
>>>> existing
>>>> EGLConfigs, also create new EGLConfigs with
>>>> EGL_TRANSPARENT_ALPHA_MESA, as
>>>> this patch already does.
>>>
>>> Yes, XRGB8888 would be the correct *technical* way to handle that,
>>> but it
>>> still makes me wonder... What about Wayland apps that expect to get
>>> transparency by simply asking for alpha now?  Won't this break them?  I
>>> guess we have to break one class of apps or the other.
>>
>> Yeah, it will break them. But then again, we had the same flag day for
>> X11 in that exact Bugzilla discussion, when X11 apps which requested
>> ALPHA_SIZE == 8 went from getting ARGB32 drawables which would be
>> blended by the compositor, to not - a change which was deemed totally
>> fine to enforce on people because it improved performance and matched
>> the spec.
>>
>> Perhaps a better interim solution is to assume for Wayland that
>> EGL_TRANSPARENT_TYPE == EGL_DONT_CARE means that applications will get
>> a format determined by ALPHA_SIZE (i.e. size 8 means ARGB32, size 0
>> means XRGB32), but respect explicit demands for
>> TRANSPARENT_{NONE,ALPHA}.
>
> FWIW, this extension was pointed out to me the other day, and I asked
> around NVIDIA for feedback on it.  We disagree with the interpretations
> of the spec that led to its development, so this and related prior
> changes will create a rift in implementation behavior.  We always have
> and will continue to support alpha blending of ARGB visuals/configs.
> We've recommended this usage to our customers and ISVs in the past, and
> have had example code explaining how to select visuals that enable
> translucency with composite in our driver documentation ever since we
> supported composite [1].  Additionally, we believe it is clear the
> EGL_TRANSPARENT_TYPE was never meant to affect alpha blended compositing
> of surfaces on the desktop.  It was meant for color-keying of overlay
> surfaces, which unlike blending, can't be expressed in the color
> channels of the config and hence requires a separate attribute.
>
> If GLES 3.x made XRGB visuals unusable, then there must be a less
> invasive solution than eliminating them entirely and forcing this entire
> new workflow on every app, including those that could care less about
> GLES 3.  Perhaps GLES 3 should be fixed, or a less invasive change to
> GLX/EGL could be made.  For example, for years we allowed using RGBA
> 32-bit GLX visuals (and EGLConfigs) with RGB 24-bit X visuals.  This
> allowed for 32-bit GLX usage while avoiding X composite alpha blending.
>   Ultimately we decided this subtly violated the spec.  Amending the EGL
> and GLX specs slightly to allow that usage and then reverting to the old
> behavior in our driver and introducing it in Mesa seems like a more
> reasonable way to resolve this.  Of course, that particular fix wouldn't
> work in Wayland, but there is probably more room for a slightly more
> invasive fix (if needed) there since the ecosystem is relatively young.
>
> Thanks,
> -James
>
> [1]
> http://us.download.nvidia.com/XFree86/Linux-x86/96.43.16/README/appendix-s.html
>
>
>> Cheers,
>> Daniel
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> -----------------------------------------------------------------------------------
>
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact
> the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------

Sorry about this.  I really hate our mail servers.  Neither this email 
nor the previous one are in fact confidential.  Everyone is authorized 
to review, use, disclose, and distribute them.

Thanks,
-James

> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev