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 <ja...@jlekstrand.net> wrote:
On Tue, Mar 3, 2015 at 10:07 AM, Chad Versace <chad.vers...@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@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
