4.3.1 plasma-desktop repain fixes
1i5t5.duncan at cox.net
Tue Aug 18 11:40:54 BST 2009
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
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
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
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
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.
More info: http://www.kde.org/faq.html.
More information about the kde