Volker Armin Hemmann posted on Tue, 25 Aug 2009 01:33:23 +0200 as excerpted:
> n Montag 24 August 2009, Sebastian Beßler wrote: >> szal...@szalkai.net schrieb: >> > Duncan please give some examples of major breakage in KDE4? >> >> I'm not Duncan but I have 5 reasons not to switch to kde4 atm. >> >> 1) Speed: I have a AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ with >> 8GB of ram and a Radeon HD 3600 card but still kde 4.3 most of the time >> feels like walking through mud. > > turn of composite or install a xorg-server with the > fedora_dont_backfill_bg_none.patch and see kde fly. In general, agreed, but there's more too it than that. Here, while I did need to make config changes, it wasn't near as drastic as turning off composite or even just window translucency, tho in testing that did work, and I didn't have to go patching my xorg either, tho that may well be the most effective for frglx users, the ones with the biggest problems dealing with that patch. The performance problem as I experienced it was a multi-headed hydra. Fixing one issue helped but there were others too. Only after dealing with (or bypassing, as just shutting off composite does) them all did I have a kde4 desktop anything close to as responsive as my kde3 desktop had been. Two of the issues had been dealt with by the time I started my real push to get kde4 working here, with 4.2.4. One kde fixed, one's still a kde issue but I had learned my way around it by that point. The one kde fixed was that in early kde4 versions, it was way to easy to set OpenGL rendering when it was broken on that hardware, as early kde4 did nothing to stop you. Not only would that result in a crash, but it would often result in kde being unable to start again, because it was now set to broken OpenGL. By 4.2.4 (and I think for 4.2.0, maybe even 4.1.something), kde had fixed that. It now tries to detect if OpenGL will work before setting it, and normally won't let you set it if it thinks it won't work. You can override it, but in ordered to do so you have to click thru several warnings, and anybody doing that should be prepared to live with the consequences. One bug down, and a very bad one at that, so good work, kde. The one I had learned around, that still exists, is that while kde now detects OpenGL compatibility and won't let you switch to it without warnings if it thinks it won't work, on the all-effects tab (of the desktop effects settings applet), there's still no indication of what effects simply do nothing in xrender/composite-only mode. One thus has to trial-and-error enable and test anything that looks interesting one by one, and if it does nothing, preferably disable it again. If they won't work anyway in xrender/composite-only mode, they should be disabled in that mode, so only the effects that actually work are available to select and try. Since most don't work without OpenGL, showing them as available to try and then having them do nothing when people do just that, is confusing at best. Dim them out and don't let people select them in that case, and usability on that tab for Composite-only users would go up several hundred percent. By 4.2.4 however, when I decided to really push toward a usable and well configured for my use kde4, I had already learned which ones did nothing, so that didn't bother me any more, other than simply knowing it continues to be an issue. That leaves the two issues I actually had to deal with in my push. By this time, Gentoo/kde had straightened out pretty much all of the kde3/ kde4 combination issues and it was possible to run a kde4 app on a kde3 desktop, or conversely, without the settings for the one being overwritten by the other. As it was obvious I wasn't making much progress trying to go whole-hog kde4, and it was now possible, I decided to try running and configuring individual kde4 apps on my kde3 desktop, so by the time I actually switched to a kde4 desktop, at least the individual apps would mostly be already configured to my liking. It was thus that I was able to discover these two issues separately, as otherwise, the one would have masked the other, and performance was so bad on kde4 that I had trouble getting anything serious at all done. So it was that I began working thru the major kde4 apps one by one on my kde3 desktop, unmerging the kde3 version so the kde4 version would be invoked when I ran the app (with FEATURES=buildpkg, I could always emerge -K the kde3 version and get back a working config if necessary, but it turned out not to be necessary) configuring them as necessary, then going on to the next one. Since kcontrol is v3 and systemsettings v4, I was able to easily invoke systemsettings as necessary from kde3 as well, thus able to configure all those without issue (well, without issue running it on kde3, at least. There was the colors issue I already posted about, and another one I might discuss later.) konsole, kmail, konqueror, all the normal apps, passed without major issue. After I got thru with the normal apps, I thought a bit about kwin, then killed the kde3 version, and launched the kde4 version, direct from konsole window. It worked! =:^) Well, sort of. kwin v4 launched just fine, and the colors as configured in systemsettings worked, and the kde4 kwin setting all took effect, but NOW THE SYSTEM WAS SLOW! I had found the first of the what turned out to be two performance issues. In Desktop Effects, All Effects tab, second from the bottom of the Appearance section, is Translucency. With it enabled (as I had it since it worked just fine on kde3), click on the wrench button to configure it. At the bottom of the left-hand column is Fading duration. This was my problem. On fading duration, if you hit the spinner, you'll note that each increment is 100 ms. I'm not sure what the default was, but it was WAY too high. While the obvious intent is that it's supposed to be the duration of the entire effect, it seems here as if it configures the duration for each step of the animation. What was obviously several hundred ms seemed to do that for each step, with the entire effect running for several seconds. Moving between one window and another just once, that worked, if it was slightly slow, but with several windows on the desktop and focus follows mouse (my default) set, it did NOT work, as now it was several seconds per transition, five, ten, twenty seconds after I stopped moving the mouse before the effects finished doing their thing! WAY WAY WAAAAYYY too slow!! The simple thing is to simply set that to instant, 0 ms. However, typing a specific value in the textbox also works, and I discovered that anything up to about 20ms was fine. But of course using the spinner, the resolution means 0 or 100ms, unless you type it in. A related setting that I didn't notice in 4.2.4 so I'm not sure if it's there or not, but that I DID notice in 4.3.0, is back in the Desktop Effects dialog, on the General tab. Animation speed, with choices of instant, very fast... extremely slow. Apparently, this controls what the "default" value in the fading duration setting above is. Of course, I now have that set to instant. But back in 4.2.4 when I discovered the problem, I'm not sure if the General tab setting was there or not, and it was the fading duration setting that I was able to configure to kill that problem. That was the first of the two performance issues I ran into. The rest of the kwin v4 on kde3 configuration went without issue, and I used kde3 with kwin v4 for several hours, no problem at all, after I fixed the duration thing. That was the last thing I could really configure from the kde3 desktop, so after that, it was time to actually try kde4 again, and see if it worked better now. Pretty much the only thing remaining to configure was the desktop itself, replacing kdesktop and kicker with plasma, when restarted X with the kde4 desktop. So that's what I did, hoping the kwin duration fix now had kde4 running smoothly. BUT KDE4 WAS STILL SLOW!! What could be the problem now? Turn off transparency just to check, sure enough the problem went away. But it couldn't be /just/ that, as that's a kwin v4 thing, and I had it running fine on kde3. So the problem now had to be the kde4 desktop itself, or rather, how it interacted with kwin. Sure enough, the second problem was plasma, but what and how? Well, I was asking myself the same question. What was different between kicker/ kdesktop and plasma, that could have plasma being slow much slower? Then I had my answer. When I had been experimenting with earlier kde4 versions, before the panels worked very well, I had put a number of plasmoids on the desktop. Back in kde3, I routinely ran the ksysguard kicker applet, monitoring cpu activity, coretemps, load, memory, etc, and as kde4 had ksysguard (aka system monitor) but no ksysguard plasmoid to replace the ksysguard kicker applet, I had the cpu temps and cpu activity system monitor plasmoids, among others, on the desktop. Of course, kde3's kdesktop was much more static. What thus ended up being the problem was all those dynamically updating plasmoids on the desktop -- triggering a bug I'll mention in a moment, but not even kde devs knew about that bug at the time, and it was too technical for users to groke. But what I decided (correctly, tho I didn't realize the ultimate cause) was that since the problem went away when I disabled transparency, and since it had to be plasma related, and since kde3's kdesktop didn't show the issue, it had to be due to all those plasmoids on the desktop -- that was the biggest difference between it and kdesktop. What I decided was happening was that with those dynamically updating plasmoids on the desktop, by themselves, everything worked relatively fine. But with several layers of windows over top, with those dynamic updates having to work themselves up the stack thru layers of semi- transparent windows, the updates to the entire stack must be killing the performance. Again, I was right, but for the wrong reason, as we'll see. Anyway, as I suspected, when I created new panels to put the widgets in and moved the widgets from the desktop onto the panels, the issue disappeared. I expected it would, because the panels are normally either hidden, or on top. There's not the multiple layers of compositing going on that I thought was the problem. So that's what I did, I moved all the widgets off my desktop. It's the bare wallpaper now, not so much as a folderview on it. And my performance is back to normal! =:^) So it took two config changes to get reasonable performance. First, kwin's translucent window effects needed set to instant. Second, at least for now, the plasma desktop can't have plasmoids, particularly dynamically updating plasmoids, on it. Either of those wrong is a performance killer, and together, they were REALLY bad. What's worse, it would have been quite difficult to figure it out, had I not taken one app at a time as I did, because the other issue would have always masked the improvement to some degree even if I /did/ get the one right. So I was very fortunate in a way, in that I did have the opportunity to run apps from the one on the other (on some distributions, that's not possible, and it wasn't on Gentoo for awhile either, because you ended up with screwed up settings every time you tried, but the Gentoo/kde folks finally got that working =:^), and in that I did have the insight to try tackling the issues a single app at a time. OK, so what's the real problem I keep mentioning? Just a couple weeks ago, one of the kde hackers realized there was a qt4 bug. The plain English version is this: On qt4 to-date, if a graphic element is entirely removed without first deleting it from the parent graphics context (think removing a widget that's no longer needed, without first telling qt to delete it from the window it had been drawing it on), qt triggers a redraw of the entire context (the entire window), instead of just the bit where the widget was at. It shouldn't matter. If the element is removed, qt should know where it was, and be smart enough to repaint just that bit, regardless of whether it was actually deleted from the drawing context first, or not. A lot of kde devs had code that did the removal without the delete first, and the last couple weeks they've been committing fixes. Some of these will make it to 4.3.1 or 4.3.1. Others might not make it until 4.4.0 Now if it's just one single event, that's not too bad, a single redraw of an entire window takes a fraction of a second, but if if that's all it is, a single event, no big deal. But guess who was one of the big users of the bad code? Right, plasma. Turns out that each plasmoid update was triggering a repaint, not for that relatively small rectangular area, BUT FOR THE ENTIRE CONTAINER. Now that's bad enough if it's a panel, but when that widget is on the desktop, ITS THE ENTIRE DESKTOP! Of course, when it's a dynamically updating plasmoid such as a temperature or CPU activity gauge, guess what, you're now repainting the entire desktop at every update of that plasmoid. And if there's several such plasmoids... That's bad enough as it is, but when it's just the bare desktop, still tolerable. But now consider what happens when that's being filtered up thru multiple layers of semi-transparent windows! No *WONDER* people with older or not well accelerated graphics cards are having issues! And on a desktop the size of mine, say 1920x2200 after the panels top and bottom are removed, still running on a vintage Radeon 9200, that's a HUGE performance issue! No WONDER I was having problems with it! According to asegio's blog, he's committed fixes for both 4.4 trunk and the 4.3 branch, which should hit 4.3.1. So now I'm looking forward to 4.3.1, to see if I can put widgets back on the desktop again. But meanwhile, its the stack of bugs such as this, that really shouldn't be appearing in an X.0 release let alone X.3, that's distressing. And it's even /more/ distressing when support for the previous very stable version is being dropped, before the current version even gets up to normal X.0 version quality, let alone the X.1 that many wait for before they consider it safe to switch. Still, regardless of the problems in version handling and premature end of support for earlier versions, good progress /is/ being made, and as I've said, I expect 4.4 to finally be what 4.0 should have been. with 4.5 finally being well polished and ready for virtually everyone, thus replacing 3.5. There's very good indications that 4.4 will meet that prediction, as should 4.5, and the finding and fixing of this bug is one of them. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
