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

[James Jones]

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.
-----------------------------------------------------------------------------------