Screenshot: http://bni.dyndns.org/resize_corruption.png Shows with: Any KDE program xterm output window in xine. Does not show with: Playlist window in XMMS Could be a problem that only shows when using kwin window manager. I killed kwin and started twm instead, no corruption is seen, same with wmaker. I restarted kwin and disabled "show window" contents when resizing, no corruption is seen. Couldnt figure out how to get another wm besides kwin to "show contents while resizing". kompmgr: "Composite" "enable", Option "AccelMethod" "EXA", "RenderAccel" "true": corruption "Composite" "enable", Option "AccelMethod" "EXA", "RenderAccel" "false": corruption "Composite" "enable", Option "AccelMethod" "XAA", "RenderAccel" "true": corruption "Composite" "enable", Option "AccelMethod" "XAA", "RenderAccel" "false": corruption xcompmgr -c -r7 -o.65 -l-10 -t-8: corruption, didnt test all options xcompmgr -a: No corruption, no matter options it seems. No Composition manager: No corruption, no matter options it seems. To sum up: The corruption is only seen when a compmgr is running with client side effects (-c) and kwin has "show contents while resizing". Test computer specs: x86, radeon 9200SE, Debian unstable (current), kernel 2.6.12-1-686-smp (Debian), Xorg CVS
assigned to wrong mail address, sorry
I was unable to reproduce on an M6 with the xcompmgr options you listed and resizing an xterm. If the xcompmgr case didn't misdraw in the same way as kompmgr, it would suggest a kompmgr bug to me (doing XAA acceleration but options NoAccel would help confirm that for sure).
xcompmgr -c -r7 -o.65 -l-10 -t-8: misdraws in the way I described. xcompmgr -a: does _not_ misdraw I also tested these options like you suggested: Option "NoAccel" "true" Option "RenderAccel" "false" Option "AccelMethod" "XAA" It gives the same results as with EXA and Accel=true and RenderAccel=true Did you try reproduce with a window manager that shows contents while resizing? I think that is what is triggering it. I could only test with kwin, but if someone else could test if metacity or some other WM shows the same, would be great.
Haven't seen this with Metacity or xfwm4. Seems to be most likely a bug in xcompmgr, maybe kwin, unlikely the radeon driver.
This sounds like the bug i opened a while ago. I closed it because I couldn't reproduce this with current CVS. https://bugs.freedesktop.org/show_bug.cgi?id=3929
I get the same thing, although a few additional things I should note. Firstly is that with dropshadows enabled, this only seems to occur when resizing a window quickly (see first screenshot). Once the edge of the dropshadow reaches an area that should be refreshed/redrawn, it is. Thus, with fast enough rendering, it could be very difficult to reproduce this. The problem can be exacerbated by turning off dropshadows (see second screenshot), in which case, window trails are always left behind, and no amount of rendering grunt will save things. Furthermore, this only happens to the bottom and right edges of a window. For example, if one was to resize a window from the top left corner, there would be no artifacts at all. The same pattern of artifacts can be seen for the rest of the edges. A final note: This somewhat fits in with the artifacts noted by the red arrows in the bottom left of the first screenshot. Small triangular artifacts can be see in the lower right of the icons, a similar effect can be seen often on the back/forward/etc buttons in Konqueror, but always only in the lower right area of the icon. These are not as easy to reproduce however. With dropshadows: http://otc.dyndns.org/xorgartifacts.png Without dropshadows: http://otc.dyndns.org/xorgartifacts_nods.png System specs: ThinkPad T40 Gentoo Linux Radeon 7500 Mobility X.org 6.9 CVS (X Window System Version 6.8.99.902 (6.9.0 RC 2), although the ebuild claims the snapshot is from Dec 1st) KDE 3.4.1 Custom built 2.6.14 kernel (although it probably doesn't matter, I have applied the following kernel patch to radeonfb to fix some suspend behaviour: http://bugzilla.kernel.org/show_bug.cgi?id=3022)
I can no longer reproduce this bug with Xorg 6.9 CVS ~20051215. Resizing windows works correctly now.
Closing, please reopen if it still happens for you.
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.