[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Volker Armin Hemmann posted on Tue, 25 Aug 2009 01:33:23 +0200 as
excerpted:

> n Montag 24 August 2009, Sebastian Beßler wrote:
>> 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