<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Qwerty,<div><br></div><div>Thanks for the suggestion. I tried both swrast and LLVMpipe. Both displayed the same problem.</div><div><br></div><div>I did, however, find a solution. There are two that were required:</div><div><ol><li>I modified my calls to glClearColor() per Brian Paul's suggestion and passed an alpha value of 1.0 as the fourth argument to the function. That solved the problem with the window contents bleeding through areas that I cleared via calls to glClear(GL_COLOR_BUFFER_BIT). Previous to this I was passing glClearColor() an alpha value of 0.0 which should have been fine because blending was not enabled. An alpha value of zero worked fine with NVidia drivers but not with Mesa.</li><li>To fix transparency rendering issue where the underlying window contents were being blended with my translucent primitives, I updated my calls to use glBlendFuncSeparate() instead of glBlendFunc():<br>Wherever I used:<br><font face="monospace, monospace">    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);<br></font>I replaced it with:<br><font face="monospace, monospace">    glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ZERO, GL_ONE);</font><br><font face="arial, helvetica, sans-serif">This allowed me to ignore any existing alpha values while blending.</font></li></ol><div>For reference, I found this information online about composite visuals on Linux Desktops: <a href="https://www.x.org/archive/X11R7.5/doc/RELNOTES.txt">https://www.x.org/archive/X11R7.5/doc/RELNOTES.txt</a></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When the Composite extension is enabled via xorg.conf or the command line, a new visual is created. This visual is different from the other visuals used by X applications in that it includes an alpha component. It is used by the compositing manager and other Composite aware applications. Most X applications ignore this visual since it is not useful to them; however some applications mistakenly try to use it, which will cause them to fail. An environment variable, XLIB_SKIP_ARGB_VISUALS, was added to the X11 library to hide this visual from applications that mistakenly try to use it. If an application fails only when the Composite is enabled, try setting this environment variable before starting the application.</blockquote></div></div></div><div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Since Composite is not enabled by default, it is not expected that this issue will be visible to most users.</blockquote></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div><div>Presumably, the NVidia drivers are composite aware with regard to visuals selected by GLX. Setting this environment variable to 1 and exporting it for my application (or glxgears) also fixed the issue without having to make the code changes to glClearColor or glBlendFunc mentioned above. </div><div><br></div><div>Thanks again to Brian and Daniel for their help with this issue.</div></div><div>Michael</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 30, 2019 at 2:01 PM Qwerty Chouskie <<a href="mailto:asdfghrbljzmkd@outlook.com">asdfghrbljzmkd@outlook.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div bgcolor="#FFFFFF">
<p>Have you considered trying using LLVMpipe instead of swrast?  LLVMpipe is much better from a performance standpoint, and may not have this bug.  You could also look into OpenSWR.</p>
<div class="gmail-m_2674479226361657143moz-cite-prefix">On 1/30/19 11:42 AM, Michael Saunders wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Brian  and Daniel,
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Michael</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 30, 2019 at 3:57 AM Daniel Trstenjak <<a href="mailto:daniel.trstenjak@gmail.com" target="_blank">daniel.trstenjak@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote">> IIRC, this is something that the window manager is doing.<br>
> <br>
> Which window manager are you using?  Maybe you need to change some <br>
> compositing setting.<br>
<br>
I had similar issues with an older Mesa version.<br>
<br>
And yes, disabling the compositing in the window manager<br>
solved the issue.<br>
<br>
But it's still not clear to me why I'm only having the<br>
issue with Mesa, but not with a NVIDIA driver. With<br>
the NVIDIA driver I hadn't to disable the compositing.<br>
<br>
So there seems to be some kind of application specific setting<br>
which causes the different behavior with Mesa and the <br>
NVIDIA driver.<br>
<br>
In our cases additionally Qt5 is involved, which complicates<br>
the case a little further.<br>
<br>
Greetings,<br>
Daniel<br>
_______________________________________________<br>
mesa-users mailing list<br>
<a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-users" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-users</a><br>
</blockquote>
</div>
<br>
<fieldset class="gmail-m_2674479226361657143mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_2674479226361657143moz-quote-pre">_______________________________________________
mesa-users mailing list
<a class="gmail-m_2674479226361657143moz-txt-link-abbreviated" href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a>
<a class="gmail-m_2674479226361657143moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/mesa-users" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-users</a>
</pre>
</blockquote>
</div>

_______________________________________________<br>
mesa-users mailing list<br>
<a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-users" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-users</a><br>
</blockquote></div>