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

[Duncan]

Volker Armin Hemmann posted on Wed, 26 Aug 2009 18:13:51 +0200 as
excerpted:

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

I wasn't aware of it checking composite (they dramatically improved that 
in 4.3.0 and I'm still discovering bits of it I didn't know about from my 
initial setup on 4.2.4), but it also checks OpenGL support, and that's 
what the warnings are on if you don't have it.

It seems you don't have an issue with OpenGL support, however, so you'd 
never see the warnings.  It would appear that just as I wasn't aware of 
some of the new composite stuff since that works just fine here, you 
weren't aware of the OpenGL stuff since that works just fine for you.

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

That popup appears whenever the mode changes, it would seem.  Composite 
toggle, it appears.  OpenGL/Xrender toggle, it appears as well.

Of course, on a system with everything working, it wouldn't appear except 
when switching out of OpenGL mode, if any OpenGL-only effects (like the 
mouse locater) are enabled.

But that doesn't cure the problem I'm talking about, which is that in 
Xrender/composite-only mode (no OpenGL), it should dim out the effects 
that require OpenGL.

For that matter, if composite doesn't work (or when it's disabled), it 
should dim out the effects requiring composite, too.  I think all the 
effects require one or the other, in which case with both disabled, the 
whole tab could be either disabled or removed.

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

Except I don't get that "nice warning".  With OpenGL off, Explode, the 
Cube, Track Mouse, Snow, Cover-switch, and perhaps others, silently allow 
enabling, no warning, they simply do nothing.  They should be dimmed out 
and not even available to be chosen, as they require OpenGL which isn't 
on.  

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

Except that only pops up when the mode is switched, not when specific 
items are enabled and/or when one hits apply.

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

Except as I've said, there are no warnings for effect toggles, only when 
the composite/opengl/xrender the mode is switched.

> KDE is about choice, you know?

Indeed.  Something we agree on! =:^)

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

This part is purely a settings thing, no more, no less.  If people are 
having trouble with performance, these settings should help, as they did 
me.  I was simply passing them on for others who may find them helpful.  
No more, no less.

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

??  I wasn't saying it wasn't userfriendly.  All I'm saying is that the 
spinner increment is too high -- don't use it when setting this, if 
you're doing it in ordered to increase performance, anyway.  Just type it 
in.  So I've no idea where you're comment is coming from.  It makes no 
sense in context.

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

Yes, kwin3 *DID* have real transparency, working with xorg composite, 
which provided the functionality.  Without composite, it didn't work, so 
yes, it /was/ real xorg based composite transparency.

In that regard, kwin4 uses exactly the same composite functionality that 
kwin3 used.

What I believe you're referring to is the "fake" transparency certain 
kde3 apps (kicker and konsole, at least) used well before xorg composite 
even appeared.  Not only were they doing it earlier, so it couldn't 
/possibly/ have used xorg's composite, but unlike the xorg composite 
based transparency of kwin3 (from 3.5.1, IIRC), it was clearly "fake" 
from a developer perspective in that all it did was take the desktop 
pixel values and blend them with the application window pixel values, to 
form a "fake" transparency that was actually simply duplication and 
blending at the individual application window level.  It was clearly 
"fake" transparency from a user perspective as well, since it didn't 
"see" any intervening windows between it and the desktop, like "real" 
composite based transparency does.

That's a mistaken generalization of fact that a lot of people make.  
konsole3 and kicker never had "real" transparency, no, it was all faked.  
But kwin itself did, using the same xorg composite extension that kwin4 
does for that and other non-OpenGL based effects.  Zooming, drop-shadows, 
the zooming based present-windows task-switcher and desktop-grid effects, 
all these are composite based, using the /same/ xorg composite technology 
kwin3 did, post 3.5.1, I believe was the version that introduced it.

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

And you know why?  It's because the graphics hardware accelerates the 
repaint, and is smart enough to realize that the entire desktop doesn't 
need repainted, despite the instructions it was handed. =:^)  But qt's 
still handing the hardware bad instructions.  The hardware's just smart 
enough to recognize and ignore the parts that haven't actually updated 
and thus don't actually need repainted.

But of course not everybody has that level of hardware acceleration yet.

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

May be, but that doesn't change the need to do the tweaks to fix the 
problem, which was what the entire post was about.  Given the problems 
others have posted, it's likely to be helpful to them as it was to me, 
and there's no reason they should have to do all the same work I did to 
rediscover what I already know, after learning it the hard way.

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

Could be, but regardless, there's people out there using such hardware, 
and the posted information both explains how I discovered the issues, and 
the workarounds and configuration tweaks necessary to get decent 
performance anyway, despite the age and speed of the hardware.

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