[Mesa-users] Mesa 18.3 swrast

Michael Saunders r.michael.saunders at gmail.com
Wed Jan 30 19:42:54 UTC 2019


Brian  and Daniel,

Thank you for your very helpful suggestions. It turns out that our software
calls glClearColor with 0.0 for alpha. I'm not sure what glxgears does but
presumably it calls glClearColor(1,1,1,0). Changing alpha to 1.0 makes the
call to glClear(GL_COLOR_BUFFER_BIT) fill the background with the fully
opaque color without any bleed-through from the underlying window contents.
Our translucent primitives, however, still blend with the underlying window
contents. When we render translucent primitives we set glColor4f with a
specific alpha value that is dependent on the desired translucency and we
use glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). Is there a more
appropriate blend function for src or dst?

It is worthy to note that the native NVidia OpenGL drivers or the default
Mesa OpenGL library backed with Nouveau drivers do not exhibit this issue.
It is only the swrast driver in the Mesa OpenGL library that I built from
source.

I did find a workaround online. Apparently by exporting the following
environment variable assignment, XLIB_SKIP_ARGB_VISUALS=1, the issues no
longer manifest. If there is a better solution to get blending to work or a
bug fix to Mesa I would prefer that over the environment variable,
nevertheless, I appreciate the suggestions given.

Thanks,
Michael

On Wed, Jan 30, 2019 at 3:57 AM Daniel Trstenjak <daniel.trstenjak at gmail.com>
wrote:

> > IIRC, this is something that the window manager is doing.
> >
> > Which window manager are you using?  Maybe you need to change some
> > compositing setting.
>
> I had similar issues with an older Mesa version.
>
> And yes, disabling the compositing in the window manager
> solved the issue.
>
> But it's still not clear to me why I'm only having the
> issue with Mesa, but not with a NVIDIA driver. With
> the NVIDIA driver I hadn't to disable the compositing.
>
> So there seems to be some kind of application specific setting
> which causes the different behavior with Mesa and the
> NVIDIA driver.
>
> In our cases additionally Qt5 is involved, which complicates
> the case a little further.
>
> Greetings,
> Daniel
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-users/attachments/20190130/2131679d/attachment.html>


More information about the mesa-users mailing list