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

[Volker Armin Hemmann]

On Mittwoch 26 August 2009, Duncan wrote:
  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.
>

no, it tries if composite works with the pre-selected composite type (either 
ogl or xrender).

And to turn off this test you only have to unselect one checkbox - without 
warnings. In fact, without that check composite works fine for me, while with 
the check my box loves to lock up with some driver versions.

xrender on the other hand is just utterly broken beyond help.


> 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.

except there is a warning popup when you enable composite telling you exactly 
which stuff does not work. Like explosion.


> 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.

even better, per default only effects that work on the vast majority of systems 
are activated. If you are turning on the rest and they don't work you get a 
nice warning message after clicking the 'apply' button. You then can unselect 
them - or don't care because they are not used anymore.


> 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.

confusing?
'Following effects could not be enabled:
Explosion'

right after the test. 
You can still enable them, in case the next driver update fixes that, the one 
you are installing in five minutes or ignore them, because they do no harm 
deactivated. 

What is not nice about it? Non working stuff is just ignored - and told so. If 
you choose to ignore the warnings - well, that is YOUR choice.

KDE is about choice, you know?


>
> 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!!
>

or you are using hardware that is way, way tooo slow. Or you are hit by the 
backfill patch fallout. Or you are using hardware that was never meant for this 
kind of stuff. 

What is your graphics adapter again?

> 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.

and you can type it in. Isn't that userfriendly?

> 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.

no. You are wrong here. kwin3 does not have 'real' transparency. Hust fake 
one. Fake one is pretty fast even on utterly broken hardware. Real 
transparency is used by kwin4. And that needs at least sane drivers and not 
hardware from yesrermillenium. You are comparing apples to oranges here.


>
> 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...

they do nothing with recent enough graphics hardware :P

>
> 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!

and now we are getting down to the interessting facts.

The short version of all your text:

'I had tried some graphic demanding stuff, turned into a even bigger workload 
by a small programming mistake on hardware that was even considered slow and 
underpowered when it was released 6 years ago.'


> 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.

you mean bugs that only hit when you use modern graphics on a 6 year old, slow 
even then, graphic adapter?