4.3.1 plasma-desktop repain fixes

[Duncan]

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.