<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Latest mesa breaks firefox on kde plasma with compositing on" href="https://bugs.freedesktop.org/show_bug.cgi?id=103699#c24">Comment # 24</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Latest mesa breaks firefox on kde plasma with compositing on" href="https://bugs.freedesktop.org/show_bug.cgi?id=103699">bug 103699</a> from <a class="email" href="mailto:lemody@gmail.com" title="Tapani Pälli <lemody@gmail.com>"> Tapani Pälli</a> <pre>(In reply to Fredrik Höglund from <a href="show_bug.cgi?id=103699#c23">comment #23</a>) > (In reply to Tapani Pälli from <a href="show_bug.cgi?id=103699#c22">comment #22</a>) > > (In reply to Fredrik Höglund from <a href="show_bug.cgi?id=103699#c20">comment #20</a>) > > > Created <a href="attachment.cgi?id=135782" name="attach_135782" title="modified test case">attachment 135782</a> <a href="attachment.cgi?id=135782&action=edit" title="modified test case">[details]</a> > > > modified test case > > > > > > The window decoration is a separate texture in kwin, so the decoration > > > should be rendered normally even if the fbconfig is causing a blending issue > > > with the window contents. I think it is more likely that binding the pixmap > > > to a texture failed, and kwin is skipping the window entirely as a result. > > > > > > > It is possible that there are 2 separate issues. One is the rendering > > results of krunner, panel and launcher menu, that is way too dark and then > > there are these invisible windows. Both get fixed by not setting sRGB > > capable config for 32bit visual, which I think is correct thing todo since > > there is only 1 such (non-conformant) visual exposed. > > Yes, I believe the dark windows is a result of Qt not using the ARGB visual > for those windows, so the background which is supposed to be translucent is > solid black. > > I don't disagree with the solution, but I don't think these are blending > issues; it's rather that applications are looking for a non-sRGB capable > fbconfig associated with the ARGB visual, and either giving up or falling > back to a non-ARGB visual after not finding one. Yep having done some more investigation I do agree it's not about blending, it's about getting wrong kind of visual. I'll wait for review comments on the xorg change.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>