During screen update (switching tabs in browser, context menu popup etc.) invalidated recs are filled with black color. Which causes uneasy flickering. It happens both with EXA and XAA. With DRI and without DRI. Server built from last commit before XACE-SELINUX merge work fine.
Created attachment 13135 [details] Black rectangle when switching tabs in browser.
Created attachment 13136 [details] Xorg config file used with faulty server.
Created attachment 13137 [details] Xorg log from faulty server.
*** Bug 13715 has been marked as a duplicate of this bug. ***
Please disable XACE by compiling with
Eamon, your comment seems to have been truncated. Could you say what option you want disabled and where? Ta! Nigel
Nevermind previous. Try the attached patch.
Created attachment 13177 [details] [review] Test Patch
Sish, just after 'make clean'. ;) Nevermind, the good thing is that above patch fixes issue for me. Thanks.
Works for me too. Thanks!
I have committed a fix to master. However, I'd like to know what desktop environments and applications you encountered this problem on. Is this occuring only on gtk or qt apps? What about non-toolkit apps such as Firefox or OpenOffice? The cause of this bug is that I changed the default behavior for windows that have a background set to "None". The previous behavior was to make them transparent which is a security problem. I changed it to solid black. Note that according to the X Protocol, background None results in "undefined behavior" so I am allowed to do this. However it looks like some toolkits and/or applications are relying on the transparent behavior.
Faulty apps: Gtk apps (gtk version 2.12.1): liferea, kazehakase (with gecko engine), gvim. Non-toolkit: seamonkey (version 1.1.5). Pure X apps (like urxvt) worked fine. I've not tried Qt or OOo.
Desktop environment: none, just fluxbox. O even single urxvt without anything else.
More tests: OOo (version 2.3.0): flickers. kcachegrind (qt version 3.3.8, kdelibs version 3.5.8): flickers.
I saw it with KDE, in the panel (especially app icons) and in thunderbird and Firefox. Not sure if I saw it in konsole.
GTK+ certainly relies on bg=None windows retaining the existing contents of the screen in many cases, to minimize flashing. The protocol spec says this: > If the background is None, the previous screen contents from other windows of the same depth as the window are simply left in place if the contents come from the parent of the window or an inferior of the parent; otherwise, the initial contents of the exposed regions are undefined. (From the description of the CreateWindow request) So as long as the windows have the same depth, I believe GTK+ is justified in relying on this.
OK, I missed that, I only read as far as the "undefined background" sentence. The old SECURITY extension did the same thing so I felt somewhat confident in the approach. I guess this is going to have to be fixed some other way, perhaps by keeping track of undrawn regions and censoring them out in the CopyArea code.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.