Re: Mesa 18.3 swrast

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 <[email protected]>
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
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/mesa-users
>

_______________________________________________
mesa-users mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-users