Created attachment 62737 [details] Corruption of UI elements in Kontact. Note icons, scrollbars, box borders. Similar effects can be observed in other applications. Version: 4.6 (using KDE 4.6.5) OS: Linux This is very likely related to: https://bugs.freedesktop.org/show_bug.cgi?id=38539 (please check there for system details) After some time of using KDE applications (minutes to hours) with a 3.0 kernel, I experience severe graphical corruption, mostly of KDE/Qt applications, including the Plasma desktop. With kernels prior to 3.0, or without the patch enabling blitting and use of GPU memory beyond the PCI aperture, I experience very frequent freezes of up to 20 or 30 seconds every time an application performs a graphically "challenging" task like redrawing its window. The freezes mostly manifest in Okular and Kopete, but many times it appears to freeze on drawing window decorations. Both happens with and without desktop effects. ======================================= Why do I think this may be a KDE issue? ======================================= Simply put, because it mostly screws up KDE/Qt applications. While closing konsole would routinely wipe out the entire desktop background in a KDE session with Plasma, I could not provoke that behaviour when running KDE applications on a Gnome desktop. Similarly, applications like Firefox very rarely show corruption. Reproducible: Always Steps to Reproduce: Start a KDE session or KDE applications on my system, run them for some time, watch graphics break. Expected Results: Graphics should not break the way they do.
Does it also happen with Desktop Effects disabled?
(In reply to comment #1) > Does it also happen with Desktop Effects disabled? Yes
a) do you use Oxygen with translucency support? b) try another UI style ("kcmshell4 style", gtk+ would be used in gnome, phase is nice, in doubt try cde or windows) -> log out/in (best press ctrl+alt+backspace to restart X11 for sure after the logout) Do the issues remain?
Created attachment 62751 [details] Showing the nature of icon corruption Using Phase style didn't help. If anything, it happened faster, and as seen in the screenshot, there's now also some uninitialised content in the affected surfaces (although I tend to chalk that one up to the general failure to erase new surfaces). This is also the first time I see so much of it in Firefox :-( Guess it's time to push Alex again on the kernel BTS.
(In reply to comment #4) > Using Phase style didn't help. Actually, hold that thought. Pure Qt apps were still using Oxygen, had to change that with qtconfig.
(In reply to comment #5) > (In reply to comment #4) > > Using Phase style didn't help. > > Actually, hold that thought. Pure Qt apps were still using Oxygen, had to > change that with qtconfig. No, really doesn't help. The errors still creep in, but slower and so far they don't appear to be affecting "UI chrome" like scrollbars, box elements, …
Ok. 1st: please ensure this as well as esp. the occasional hangs are NOT related to kwin. Eg. install openbox or metacity and run "openbox --replace &" This will change the WM. -> do the issues remain? 2nd: please ensure it's not Qt's graphicssystem. There are 3. Try "okular --graphicsyystem native", "okular --graphicsyystem raster" and "okular --graphicsyystem opengl". Is one or are both issues related to this setting? 3rd: check whether X11 leaks pixmaps. run "xrestop" and check whether some process own an extraordinarily large amount of pixmap (it's pretty much normal that plasma-desktop sucks quite some. It's the wallpaper ;-) Also kwin will require some when compositing because of the offscreen buffering. The number should drop as soon as you suspend compositing) The KDE version (4.6.5) is btw. correct?
(In reply to comment #7) > 1st: please ensure this as well as esp. the occasional hangs are NOT > related to kwin. Eg. install openbox or metacity and run "openbox > --replace &" > This will change the WM. -> do the issues remain? Yes > 2nd: please ensure it's not Qt's graphicssystem. There are 3. > Try "okular --graphicsyystem native", "okular --graphicsyystem raster" and > "okular --graphicsyystem opengl". Is one or are both issues related to this > setting? "native" causes the hangs as usual, "raster" doesn't (since it doesn't seem to allocate surfaces, which is what causes the hangs), "opengl" crashes the kernel side of the graphics driver. > 3rd: check whether X11 leaks pixmaps. run "xrestop" and check whether some > process own an extraordinarily large amount of pixmap (it's pretty much normal > that plasma-desktop sucks quite some. It's the wallpaper ;-) Also kwin will > require some when compositing because of the offscreen buffering. The number > should drop as soon as you suspend compositing) Doesn't seem like anything really leaks. Firefox hops all over the place (the Downloads list is one ugly mother), the desktop is pretty static, and kontact gobbles up pixmaps until it hits a ceiling. The Quassel client also seems to be quite intensive (maybe Qt list views having something to do with that?) > The KDE version (4.6.5) is btw. correct? Yes, that seems to be what Debian unstable has at the moment. The About dialogues say "KDE Development Platform 4.6.5 (4.6.5)", Qt version 4.7.3. The corruption really feels like a race *somewhere*, but it's really curious that it tends to just chop a bunch of pixmaps in half—most times the same pixmaps in the same way too!—and not cause crashes or other funky issues. I'd be really glad if I at least knew who to blame :-P
> I'd be really glad if I at least knew who to blame :-P Not KWin - that's now for sure. "export QT_GRAPHICSSYSTEM=raster" will use it globally and thus might lower your pain. It still does allocate surfaces, but much less (only for the final onscreen drawable, aka "window" and the doublebuffer) - everything else happens in RAM. The blame game likely points the GPU/driver - or your HW is broken ;-P (But the OP backs the driver) and it's pot. related to the KApplication constructor causing a lot of action on the QPixmap side (Just replacing "new QApplication" by "new KApplication" caused floods in nvidias pixmap cache here) While that action (possibly related to the icon system?) might trigger the issue, this is rather no KDE issue. I assume if you just put enough load on this otherwise, similar issues will occur. :-\ I really do not suggest that as "solution" (it's not) but can/have you checked the results with fglrx?
very likely not an issue which KDE is responsible for. Because of that setting to UPSTREAM. I am sorry that we cannot provide any further help :-(