I've been following the various planet QGraphicsScene (QGS) delete-before- remove comments with interest. For those new to the story, it seems someone recently discovered that deleting items from a QGS before removing them from the scene caused a full view repaint, thus causing far slower graphics redraw than should be the case, if it redrew only the area where the deleted item had been. Apparently quite a lot of KDE code did just that -- delete-before-remove -- thus triggering way slower graphics redraws and way worse performance than should have been the case. Regulars may remember how I complained that kde4 was (initially) for me (on my old Radeon 92xx based graphics and dual 1920x1200 LCDs stacked for 1920x2400, thus larger than the 2048x2048 square that said graphics can handle OpenGL on, thus limiting me to XRender effects) *WAY* slower than kde3 on the exact same hardware and base software system. Eventually, I got tired of trying to work with and reconfigure to usefulness for me all of kde4 at once, as it was just too much to do all at once, and the responsiveness too slow. Thus I started using individual kde4 apps on a still kde3 base, configuring and tweaking one at a time. After I had configured most individual apps, it came time to switch out kwin3 for kwin4 (still on a base kde3 desktop). That's where I discovered the first performance issue, that kwin4's compositing effects were FAR slower than kwin3's. Since I was now working one app at a time and thus had it nailed to kwin, since that was what triggered the slowdown, I was eventually able to trace that one to a default effects delay setting that was just way too high, at least for my hardware, which seemed to interpret it as delay-per-step when the intent was clearly total delay. The default spinner widget increments were 100ms, 0, 100ms, 200ms, etc. But in the edit-box next to the spinner one could type in single ms increment values, and I found a value between 1 and 20 ms FAR better than the default of several hundred (it just said default, so I have no idea what it was except that the increment was in 100 ms increments, so it had to be several hundred as it obviously wasn't zero). That was one of two performance critical configuration issues I ultimately found. The other I discovered when, having configured each individual kde4 app and kwin4 as optimally as I could, I finally switched back to a full kde4 desktop -- basically switching in plasma for the combination of kicker and kdesktop, thus making it the biggest change of the switch from a base kde3 to a base kde4 desktop. Performance once again dropped, and now I knew it had to be in plasma-desktop. It turned out that putting all those plasmoids on the desktop, composite- rendered thru multiple layers of application window, was just too much for my poor aging Radeon 92xx graphics. Since kde3's kdesktop was basically static, no such widgets to render, it wasn't a direct comparison and composite rendering there was noticeably faster. Once the problem was understood, the fix was relatively simple, kill all the desktop plasmoids, either putting them in panels, or simply deleting them, returning the desktop to the relatively static space it was in kde3. Since the panels were normally either hidden or always-on-top, with the windows maximizing to the edge of the panel not over top of it (and if the window was moved, it moved /under/ the panel), the panels didn't have multiple layers of windows composite rendering on top of them, and performance was MUCH better! It helped that panel management was far better in 4.2 than it had been earlier, when I had initially setup all the desktop plasmoids because 4.0 and 4.1 had such poor panel management I really /couldn't/ get the plasmoids on the panels as I would have liked. That was the status as of 4.2.4, when I did my switch, continuing into 4.3.0, current release. The combination of those two fixes, setting a far faster effect time than the default for kwin composite, and moving all the desktop plasmoids off the desktop, either into the panels that now worked well enough to handle them acceptably, or deleting them entirely, finally make kde4 performance acceptable, and I was finally able to switch to it for general use. Then shortly after I upgraded to 4.3.0, I decided it was working well enough I could finally uninstall kde3. But, it seems there was somewhat more to the story than that. As I said above, I've been following all the QGS delete-before-remove comments and activity on KDE-planet with interest. As it happened, Aaron Seigo, lead plasma dev, was in the midst of moving when this discovery and the initial code changes based on it went down, so he has been somewhat out of the picture for all of it... until now. His latest blog posts notes that yesterday (Monday) was his first full day back on the net, and that of course he had a LOT of catching up to do. Well, all this QGS delete-before-remove stuff was part of his catching up, and he immediately realized the implications for plasma, which had apparently been doing it wrong, as had so many other kde apps. He has now checked in (for both 4.4/trunk and 4.3/branch for 4.3.1): > a nice little set of optimizations that prevent full-screen repaints > in plasma-desktop when just moving your mouse around over widgets. WOW! That sounds like /exactly/ the sort of performance drain I had observed with plasmoids on the desktop! Now I'm *SERIOUSLY* looking forward to 4.3.1! Maybe, just maybe, I can put plasmoids on the desktop again, without having the whole session gggoooo iiintttoooo sssllloowwwmmmo! =:^) http://aseigo.blogspot.com/2009/08/arrivals-through-barrel-of-time-gun.html Seriously, if whole desktop repaints were being triggered, not just little bits of the plasmoids that updated, not even just individual plasmoids, but the whole desktop, AND that was having to propagate up thru 2-3 layers of window compositing, that would make a HUGE difference, particularly on close to a full 1920x2400 resolution (assuming panels and etc wouldn't have been included in the repaint)! No WONDER my poor old hardware was going all draggy. No WONDER moving the plasmoids to the panels worked so much better, even if the whole panel repaints, as they're so much smaller, and as I thought was the whole issue initially, don't have to propagate changes up thru several layers of composite windows, too. It's exactly this sort of problem that has so many people still calling kde4, even 4.3.0, barely beta quality, at least in comparison to the so mature and well polished kde 3.5 that despite protests to the contrary, kde is gradually defaulting to unsupported status. (To be fair, the problem is as much how great kde3 is, after years of polishing, feature enhancement, and bug squashing, as it is kde4. In that regard, kde4 has much the same problem as a super-achiever's kid brother does going to the same high school, trying to fill the shoes of the captain of the football team, the president of the student body, the president of his class... /anybody/ would have trouble filling /those/ shoes, so it's no surprise kde4 has trouble. But it doesn't help when the kid brother makes problems for himself, as kde4 has done...) Had support, both from kde "upstream" and from the distributions, remained strong for kde3 until kde4 reached reasonable maturity -- which it is doing but it takes /time/ and /hard/ /work/, plus some reasonable change-over period, things would have looked far different and kde wouldn't have gotten such a bloody nose reputation and PR-wise. Now that this bug is fixed, if only the already filed bugs in ksysguard4 (it won't properly take and retain ranges on its plotters, and there's no plasmoid replacement for ksysguard3's kicker applet) and khotkeys4 (it doesn't handle global multikey) can be fixed, kde4 will be very close to full kde3 functionality in the stuff I actually use. Well, that and the networking bug whereby konqueror and other kde4 apps often fail to work properly when connecting thru a local proxy. Unfortunately, the khotkeys4 bug doesn't seem anywhere close to resolution, as it's apparently relying on behavior provided by some other part of the software stack. But I've installed xbindkeys as a non-kde alternative and am working on converting my hotkey config to it, already, so kde4's brokenness in that regard won't be slowing me up much longer, either. But kde3 and the difficult transition is mostly behind me now, kde4 is getting there, and this fix is certainly something to look forward to in 4.3.1 and beyond! =:^) -- 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 ___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.