Bug 22566 - random artifacts whith Composite extension enabled (frequently seen with QT, but not exclusive)
random artifacts whith Composite extension enabled (frequently seen with QT, ...
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Server/General
unspecified
Other All
: medium normal
Assigned To: Ville Syrjala
Xorg Project Team
2011BRB_Reviewed
:
Depends on:
Blocks: xserver-1.11
  Show dependency treegraph
 
Reported: 2009-06-30 17:47 UTC by Clemens Eisserer
Modified: 2011-10-24 10:10 UTC (History)
12 users (show)

See Also:


Attachments
Xlib only testcase (1.85 KB, text/plain)
2010-09-24 11:00 UTC, Clemens Eisserer
no flags Details
windows "holed" under icewm (20.85 KB, image/png)
2010-10-11 03:47 UTC, Clemens Eisserer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Clemens Eisserer 2009-06-30 17:47:27 UTC
Sometimes KDE4's popups cause corruptions on (what looks like to be) random places on screen. The corruption has the shape of the popup, and where it occurs the desktop background shines through the application window.
This seems to happen randomly, I wasn't successful to find a pattern.

The bug-report states that disabling the composite extension makes the problem go away, however I haven't verified this solution my own.

The bug reported by me: https://bugs.kde.org/show_bug.cgi?id=198481 (screenshots and further details)
has been dupped as an report of: https://bugs.kde.org/show_bug.cgi?id=173686

This happens both with vesa+shadowfb, as well as intel-2.8-prerelease so I don't think its driver related. I've experienced it with xorg-1.6.0/1 as well as 1.6.99 shipped with fedora rawhide.
Comment 1 Amit Shah 2009-07-01 10:15:14 UTC
It's not random, as described in

https://bugs.kde.org/show_bug.cgi?id=197602

and

https://bugs.kde.org/show_bug.cgi?id=184314

There also are videos on both the above links that show the effect.

If you have multiple toolbars, go to one of them and wait for a tooltip to pop up. Then go to the second toolbar and wait for the tooltip. The area in which the first tooltip was displayed is then corrupted and the desktop background becomes visible just in that space.

I have this problem on a ThinkPad X200 which has an Intel graphics card with KMS enabled. With desktop effects enabled, this doesn't happen. It happens with effects turned off for me. But there are others in the KDE bug tracker who say acceleration doesn't seem to matter.
Comment 2 Basti 2010-02-22 12:39:16 UTC
I can confirm  that bug like Amit Shah described it. Please fix it, it’s sooo annoying -.-
Comment 3 Clemens Eisserer 2010-02-22 15:03:33 UTC
still there with xorg-1.7.5

Its really annoying, please fix it :/
Comment 4 Laurent Bonnaud 2010-09-07 03:08:31 UTC
I am still seeing this bug in Ubuntu 10.04, Xorg 1.7.6 and KDE 4.5.1 with the fglrx driver.

Same thing with Debian squeeze, Xorg 1.7.7 and KDE 4.4.5.

This bug has existed for ages with all KDE4 versions and all Xorg drivers (I tested various intel driver versions, the radeon driver, the fglrx driver and the nvidia driver).  For drivers that support KMS, enabling or disabling KMS does not make this bug disappear.

Therefore I guess that this bug is in a core part of the server.
Comment 5 modulistic 2010-09-09 06:22:51 UTC
This is happening to me with composite disabled. Perhaps this can be confirmed by someone with more background on xorg/kde and so bug title could be updated with more confidence.
Comment 6 Roman 2010-09-24 02:17:55 UTC
Confirming it affects me too, all KUbuntus since Jaunty till Lucid, probably will go to Maverick. Compositing should be disabled (enabling KWin effects removes the problem, but it is slow due to my video card).
KDE 4.4.2, X server 1.7.6
The graphical trash can be reproduces exactly as it is described in the comment 1.
Tested with intel and nvidia graphics.

I wonder why this bug lives so long - it constantly moves from one distribution to another. It just becomes more and more annoying due to its survivability.
Comment 7 Clemens Eisserer 2010-09-24 03:04:28 UTC
> I wonder why this bug lives so long - it constantly moves from one distribution
> to another. It just becomes more and more annoying due to its survivability.

I guess its because of:

- Two projects are involved, KDE and Xorg. This already led to the usual finger pointing. This way no problems are fixed.

- Its quite hard to reproduce. I also get this corruptions, but can't trigger then as easily as shown in the KDE bug reports.

- KDE isn't *the* major desktop environment anymore, it has become an alternative to gnome for most distributions. So distributors don't care enough to pay somebody to track this bug down and fix it.
Comment 8 Michel Dänzer 2010-09-24 03:15:01 UTC
(In reply to comment #7)
> - Two projects are involved, KDE and Xorg. This already led to the usual finger
> pointing. This way no problems are fixed.
> 
> - Its quite hard to reproduce. I also get this corruptions, but can't trigger
> then as easily as shown in the KDE bug reports.

It would help for these issues if there was a simplified test program (not using Qt but direct X calls) reproducing the problem. That should help demonstrating that it's indeed a bug in X as well as fixing it.
Comment 9 Roman 2010-09-24 05:55:36 UTC
(In reply to comment #8)
> It would help for these issues if there was a simplified test program (not
> using Qt but direct X calls) reproducing the problem. That should help
> demonstrating that it's indeed a bug in X as well as fixing it.

I feel it is just not realistic to expect such a thing from usual users, which are not involved in the development of KDE/Qt/X. If it is what the developers are waiting for, then the problem will never be fixed, most probably. Obviously, the graphical corruptions that we a speaking about require some rare conditions to meet together, and thus would hardly occur in a simple app. If someone can provide such a simple test app for this rather complicated bug then he already knows the source of the problems himself and probably understands how to fix it. Then he can just say how to fix it. Thus, this essentially means to wait until some external person find a fix for the bug.
Comment 10 Clemens Eisserer 2010-09-24 10:59:49 UTC
Spent quite some time trying to create an XLib-only testcase, found out by accident that the problem seems resizing/moving unmapped ARGB32 windows.

The testcase attached demonstrates the issue, in a few seconds I have a desktop full of perforated windows, regardless of the windowmanager used.
Running a composition manager makes the problem disappear for me, just like as for KDE.

I've also recorded a short video: http://www.youtube.com/watch?v=_d9DCEAZfNA
Comment 11 Clemens Eisserer 2010-09-24 11:00:49 UTC
Created attachment 38941 [details]
Xlib only testcase
Comment 12 Christoph 2010-09-25 08:09:01 UTC
I can reliably reproduce the bug using the attached test case on my system.
Comment 13 Roman 2010-09-26 02:46:34 UTC
(In reply to comment #11)

Cool, it works!
Comment 14 Michel Dänzer 2010-09-27 04:35:48 UTC
(In reply to comment #10)
> Spent quite some time trying to create an XLib-only testcase, found out by
> accident that the problem seems resizing/moving unmapped ARGB32 windows.

Thanks Clemens, this looks very helpful.

Trying to get the attention from the 1.9 release managers / the author of the Composite extension.
Comment 15 Clemens Eisserer 2010-09-29 07:30:45 UTC
Thanks Michel for taking care of this bug :)
Comment 16 Michel Dänzer 2010-09-29 07:36:12 UTC
Note that on a quick test I couldn't seem to reproduce the problem with Clemens' test case on recent xserver Git. Has anyone reproduced the problem with xserver 1.9.x or even 1.8.x?
Comment 17 Christoph 2010-09-29 07:48:56 UTC
Yes, I use openSUSE 11.3 which has server 1.8.0 and see the problem when I run a non-compositing window manager (KWin with compositing disabled) while the compositing extension is enabled (which is the default when you have no xorg.conf).
Comment 18 Clemens Eisserer 2010-09-30 02:33:30 UTC
I can reproduce the problems on "X.Org X Server 1.8.2"
Comment 19 dmatt 2010-10-03 11:04:57 UTC
I did reproduce the problem with X.Org 1.9.0 on new Kubuntu 10.10 RC as well as on OpenSuse 11.3, which is 1.8.x I suppose.

How to reproduce the bug reliably is described in https://bugs.kde.org/show_bug.cgi?id=253078 . That bug was closed as duplicate of this bug.

I get this bug only when composition is disabled contrary to what main heading says.
Comment 20 Christoph 2010-10-03 16:44:44 UTC
dmatt, don't confuse "compositing" and "composite extension" enabled :)
Comment 21 dmatt 2010-10-03 17:33:06 UTC
(In reply to comment #20)
> dmatt, don't confuse "compositing" and "composite extension" enabled :)

Everyday I learn something new :)
Yes I am the case of disabled compositing and enabled compositing extension.
Comment 22 Clemens Eisserer 2010-10-05 13:12:22 UTC
so, any idea what could cause this?
It looks like expose events are sent to the wrong windows somehow.
Comment 23 Roman 2010-10-11 02:15:42 UTC
I am beginning to doubt that the bug is indeed in X, because I can not reproduce it in pure X (without KDE or any other DE and any window manager, starting it via xinit).
The holes in application windows and various graphical elements can appear only after I launch manually 'plasma-desktop' (this loads desktop and panels, but still no window manager). This suggests the bug may be actually located in plasma. Is it reproducible using the Clemens' testcase in something else than KDE (e.g. gnome)?
Comment 24 Clemens Eisserer 2010-10-11 03:47:00 UTC
I can reproduce the problem with icewm too, and I doubt plasma is involved in this problem at all - it hasn't any way to influence the expose-handling of windows.
Comment 25 Clemens Eisserer 2010-10-11 03:47:27 UTC
Created attachment 39341 [details]
windows "holed" under icewm
Comment 26 Daniel Scharrer 2010-10-11 03:55:06 UTC
(In reply to comment #23)
> I am beginning to doubt that the bug is indeed in X, because I can not
> reproduce it in pure X (without KDE or any other DE and any window manager,
> starting it via xinit).
I can reproduce this with just X, twm xterm and xeyes as well as the testcase attached to this bug (started several times to get holes faster). With the client areas of xeyes and xterm overlapping, the test case app causes the contents of the xeyes window to be painted over the xterm window in front of it.
I used a pretty much empty xorg.conf containing just stub sections, so no extensions have been disabled/enabled.
Comment 27 Clemens Eisserer 2010-11-13 03:07:09 UTC
It took me a really longt ime to come up with this testcase, as it has been requested.
Now there is a testcase, triggering the problem on many machines and still no progress :/
Comment 28 Clemens Eisserer 2010-11-30 04:44:27 UTC
I noticed a subtile thing, windows located at (0,0) don't seem to be affected by the corruptions.

As sson as I move firefox away from the top-left corner, I see the artifacts - as soon as I move it back no new artifacts appear.
Comment 29 Roman 2010-11-30 06:54:48 UTC
In my KDE 4.4.2 the windows at (0,0) can be corrupted just as easily.
Actually I noted the following rule (in KDE): the corruption (a hole in the place where some old tooltip was previously drawn) occures only if the new tooltip (the one which triggers the hole) does NOT cover the window which should be holed. Due to this, the maximized windows are never holed by KDE tooltips. But this rule seemingly does not apply to your testcase: it corrupts just all existing windows.
Comment 30 Clemens Eisserer 2010-12-20 15:02:49 UTC
I was able to reproduce the bug with xorg-x11-server 1.9.99.1-2.20101201 shipped as part of Fedora rawhide. 

Just download the KDE live cd, and start the holer testcase.
Comment 31 cyberbeat 2011-01-26 05:46:39 UTC
please(!!!!) someone try to fix this bug. who maintains the responsible code part?
Comment 32 rsimmons0 2011-04-14 00:48:20 UTC
Well, this bug is still around for me.  I initially reported it to KDE as
https://bugs.kde.org/show_bug.cgi?id=267641

I have upgraded to KDE 4.6.2 since reporting the bug, but it's still here.
Comment 33 Clemens Eisserer 2011-04-14 04:15:33 UTC
here for me to. at least it has been moved from 1.9.x blocker bugs to 1.10.x, so hopefully it will get some attention.
Comment 34 Roman 2011-05-05 03:41:41 UTC
I cannot reproduce this bug in KDE 4.6.2 (XOrg 1.10.1) with KUbuntu Natty during the routine work. The action sequences that previously corrupted panels and windows with 100% chance, no longer corrupt anything. I tested this on two machines, with intel and nvidia graphic cards. I am really happy not to see these corruptions now.
However, the holer testcase from here still corrupts the desktop as previously. This may indicate that the bug is not really fixed and can re-appear again in future releases.
Comment 35 Roman 2011-07-03 03:31:11 UTC
After a couple of months of working with KUbuntu Natty I find that these graphical corruptions still may occasionally appear (mainly the panels get corrupted). However, they became very seldom, and I cannot figure out how to reproduce them "naturally" (not using the testcase from here). The testcase still works as previously.
Comment 36 Jeremy Huddleston 2011-09-24 16:17:28 UTC
Please test with xorg-server-1.11.1.  We believe that this is probably fixed in 1.11.  If there is no response in the next month, this issue will be closed as presumed fixed.  See http://lists.freedesktop.org/archives/xorg/2011-September/053561.html
Comment 37 Clemens Eisserer 2011-09-27 04:55:17 UTC
I can still reproduce the problem with 1.11.0, shipped with Fedora-Beta-RC3.
There is a simple, self-containing test-case attached, so developers should be able to reproduce the issue themself easily.

Please change bug status to "New" again.
Comment 38 Jeremy Huddleston 2011-09-27 11:22:56 UTC
Over to Ville
Comment 39 Ville Syrjala 2011-10-08 16:08:41 UTC
Just posted a fix to the mailing list: http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/25664
Comment 40 Jeremy Huddleston 2011-10-24 10:10:49 UTC
This has been merged to the 1.11 branch and will be in 1.11.2 RC2