<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - GNOME notification icons drawn all-black" href="https://bugs.freedesktop.org/show_bug.cgi?id=51360#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - GNOME notification icons drawn all-black" href="https://bugs.freedesktop.org/show_bug.cgi?id=51360">bug 51360</a> from <a class="email" href="mailto:leio@gentoo.org" title="Mart Raudsepp <leio@gentoo.org>"> Mart Raudsepp</a> <pre>The exiting out of the loop approach would defeat the purpose of a lot of the changes made by Frank in that area, in particular handling of destination drawing area being larger than the source pixmap for PictOpSrc cases (but not negative srcX/Y, just larger drawing width/height than source pixmap dimensions). So after some brewing I pushed a different variable tweaking commit that should just make it so that only the source pixmap is composited in this specific case that was completely mishandled before (negative srcX/Y), which should even be correct for PictOpOver, but not so much for PictOpSrc - but I believe not much cases in the wild should need that black rendering for borders, as that's quite undesired to have random black borders in real applications I bet. In the icon case, I believe the rendering is actually to some different pixmap and the black part isn't shown on screen. A more extensive and full fixing is in order in the future and I have a good idea what to do there, but such changes wouldn't be suitable for an impending stable bugfix release, so hopefully in a major version later on. Please test the version pushed to GIT if possible, and see that it fixes the icon bug and doesn't cause any regressions elsewhere.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>