KDE Desktop effects

[Duncan]

Bogus Zaba posted on Sun, 16 Sep 2012 17:21:15 +0100 as excerpted:

> On 09/15/2012 03:40 PM, Duncan wrote:
>> Bogus Zaba posted on Fri, 14 Sep 2012 19:59:15 +0100 as excerpted:
>>
>>> I am not desperate to have all possible eye-candy operating, but I
>>> know that my system is capable of reasonable performance with regard
>>> to stuff like box-switching etc because it has worked before.

FWIW, I know the feeling.  I remember having a similar feeling a few 
years ago when I first upgraded to the then still incredibly buggy "alpha 
grade" (despite kde claims to the contrary) kde 4.2.  While I've since 
upgraded hardware, my workflow had come to depend on semi-transparent 
windows in the kde 3.5 era, so I knew there was absolutely no valid 
reason that kde4 couldn't handle at least window transparency.

I was correct, too.  IDR the exact version now, but IIRC it was near 
4.3.2, when one of those serious bugs was fixed, and kde4 suddenly became 
*MUCH* more usable, speed-wise, tho by that point I had configured around 
the worst of the problem.

The point is, when you know what a system /can/ do, it's difficult to 
take people saying it can't, that you need better hardware, when you know 
it DID work and still does with the old version, so the fact that it's 
not doing so now is evidence of a serious software bug.

>>> The system has an nvidia GeForce 7300 card and I am using the nvidia
>>> (proprietary) driver. The KDE is 4.5.5 under Slackware 13.37 which is
>>> the best I can run under Slack 13.37 without making some other
>>> significant system changes.
>>>
>>> Recently KDE [is forcing jerky/slow] XRender. If I try and switch to
>>> OpenGL I get "Failed to activate[" and reversion to XRender.
>>> Reinstalling the nVidia driver doesn't help, and its opengl checks
>>> out.]

>> [Did you recently upgrade anything?  Upgrading one component to newer
>> while keeping the system in general older might do this.]

> Kernel is 2.6.37.6 - as supplied with Slackware 13.37.
> xorg-server seems to be 1.9.5 as supplied with Slackware 13.37.
> The nvidia driver is 295.33 as supplied by the semi-official
> "Slackbuilds.org" repository.
> 
> So none of the above are very recent upgrades - all about 1 year old.

OK.  The list of immediate suspects seems to check out.  Nothing 
interesting there.

> As I was getting this information together I remembered that there was a
> published reliable way of upgrading to KDE 4.6.5 from 4.5.5 without
> making major changes to the system, so I went ahead and upgraded. All
> seems to have worked well - KDE reports that it is now at 4.6.5, but
> same message when I try and switch from Xrender to OpenGL for desktop
> effects.

No luck there.  Frustrating!

>> Just to confirm.  There's an app called glxgears.  [Can you]
>> see the gears still?  If so, you have at least /minimal/ glx

> Check - this works fine and glxgears reports about 1700 fps.

That was a long shot anyway, but it's still useful confirmation.

>> IDR if kde 4.5 had it or if it was added later, but if you have a
>> checkbox for opengl shaders, try unchecking that.

> Here are the options on this tab (in KDE 4.6.5):
> * Disable functionality tests (right under the compositing type
> drop-down list. This is checked.

FWIW, while I remember that option now that you mention it, it's gone in 
newer versions (from 4.7 I think, it had a number of DRAMATIC kwin fixes/
improvements).  There were some specific bugs that it was there to allow 
working around, but they've been addressed now.  I believe I remember 
reading a kwin dev's blog entry on it around that time, but unfortunately 
the details are fuzzy now.  But after addressing the problems it was 
there to provide a workaround for, the option was either useless or 
causing more problems than it solved, so it was removed.

FWIW, the new method finally defaults to a much saner effects off until 
enabled policy, as well as testing the functionality for each individual 
effect and disabling just that (with a notification on which specific 
effects couldn't be enabled) when effects are switched on.  There's an 
option to enable effects automatically on login (on the left/first tab 
where it's more visible), but it's OFF by default, and there's a warning/
confirmation dialog asking if you're sure you want to enable them by 
default, since that could keep you from getting into kde if something 
goes wrong, when you do enable it.

In general, then, things are MUCH more robust now.  I really do wish 
they'd had it working this way by the time they called kde4 ready for 
normal use with 4.2, as it would have dramatically improved the early 
kde4 user experience, but too late for that now.  At least it works the 
way it should have all along, now. =:^)

> * Keep window thumbnails (This is set to "never")

That option's still there (in 4.9).  I've actually tried it with all 
three settings, but don't see much difference.  The "breaks 
minimalization" warning doesn't seem to be entirely true, however.  
Minimalization still works, but I think it does break thumbnailing from 
the tasklist plasmoid, which I don't happen to use anyway, so I don't see 
it.

> * Scale method (Set to "crisp" rather than "smooth")

That's still there.  On a reasonable GPU smooth should be fine but crisp 
is definitely the best for troubleshooting or if you're having speed 
issues.

As I'm running a radeon "turks" hd6770 now (freedomware drivers, the 
northern islands series of which turks is a part are the latest fully 
supported hardware, southern islands are newer, but WAY more expensive 
and not as well supported yet, with the freedomware driver anyway), I 
really don't notice much of a difference in either speed or quality 
regardless of the setting (tho I have it set to accurate, purely because 
I can), but crisp is the best choice if you're seeing speed problems, 
particularly since it /doesn't/ seem to dramatically affect quality.

FWIW, one of the "DRAMATIC improvements" I mentioned is much improved 
help.  For this one there's now a tooltip that has an explanation for 
each option.  Crisp uses GL_NEAREST and is said to be fast on all GPUs 
but "bricky".  Smooth uses GL_LINEAR and is said to be fast on most GPUs 
but a bit "blurry".  Accurate requires Lanczos filter functionality and 
shader support.  There's a warning that it could be slow or even trigger 
crashes on weaker GPUs, and recommends falling back to Smooth should that 
happen.

> * OpenGL mode (Set to "Fallback" rather than "Texture from pixmap" or
> "shared memory"

THAT option's missing, now, tho again I remember it.  It may be that the 
Use Opengl 2 Shaders option I mentioned replaced it.  Or it may be that 
it's not needed, now that they auto-detect individual functionality.

I do know that at least Radeon hardware of r600+ chips or newer (nearly 
all the hdXXXX series, the xXXX series were r3xx-r5xx and the numbers 
only models were the original radeon r1xx thru r2xx) works very well with 
texture-from-pixmap and believe that's what I had set with my rv730/
hd4650.  In fact, texture-from-pixmap works SO well on radeon that it's 
what they use to implement the old overlay video mode on newer GPUs.

I also know that my radeon hd4650 (rv730) was broken with OpenGL 2 
shading, once that option was available.  That actually locked me out of 
kde for awhile, as I have the enable effects at startup option set.  I 
had to rename the kwinrc file to get back in, then experiment a bit to 
figure out what option was the problem.

But when that system (which was still AGP) died and I upgraded to a PCIE 
system, of course I had to upgrade graphics cards accordingly, and my 
newer radeon hd6770 (turks, they did away with the rXXX chip numbering, 
northern islands series) works *VERY* well with shaders, etc.

But I've little idea whether/how any of that maps to nVidia, and indeed, 
no idea how recent/old your gforce 7300 might be.

> * Enable direct rendering (Checked)

This option's gone, now, tho AFAIK it can still be controlled via 
environmental variable.  I really should try experimenting with that 
again, since the last time I did was on the old system.

(This is what I have in my .bashrc regarding the variable.  As you can 
see, it's commented ATM, so I should have direct rendering.)

# KDE4 kwin OpenGL composite
# http://dot.kde.org/1195074194/1195113392/1195122064/
#export LIBGL_ALWAYS_INDIRECT=1

When the option was there, I tried experimenting both with it and with 
the environmental variable.  It didn't seem to make a lot of difference, 
but one way, one effect broke while another worked, the other way, 
reversed.  I really wanted both effects, but couldn't have both.  (The 
effects were opengl-accelerated color-invert, and snow.  But the snow 
effect disappeared from the list some versions ago... you probably don't 
even have it in 4.6, so...)

> * Use vsync (also checked)

This option's still there.  At least older radeon drivers used to enable 
vsync by default, however, limiting for instance glxgears to the 60 Hz 
refresh rate of my monitor.  It was possible to disable vsync and get 
full speed glxgears, but I had to do it via X/DRM config, the option here 
had little effect.  Of course tying to refresh rate is arguably a good 
idea since you can't see what the monitor hasn't had time to draw in any 
case, but it did put a kink in my ability to compare framerates against 
others I saw published.

On a current software stack, however, while the option's still documented 
for the driver, if it still does anything at all, it's not affecting 
glxgears anyway, as it's reporting full rates, now, and did so on my old 
system as well, so it's not hardware related.  (FWIW on my current hd6770 
hardware with native drivers, glxgears reports 2000-3500-ish FPS at the 
default window size.  That's with effects enabled including window 
transparency (tho if I use the zoom effect to zoom in, framerates drop 
DRAMATICALLY, to only 113-166 or so, I wouldn't have expected THAT big a 
drop, particularly when effects toggle in general and transparency, 
which /used/ to have a big effect, has approximately zero effect now, 
but...).  Even at the full size spread across two monitors stacked for 
1920x2160, I still get 60-80 fps, above the 60 Hz monitor refresh-rate.  
But glxgears is pretty basic glx so hasn't been a good benchmark for 
years, tho it does still serve its purpose as a quick basic glx-working-
at-all-or-not test, which is why I asked about whether it worked at all, 
not about its reported framerates, above.)

> I have played randomly with many of these but no combination that I have
> tried has fixed the won't-switch-to-OpenGL problem.

My experience with being locked out of kde due to the shaders option was 
why I asked about it.  But I guess you don't have it to check on 4.5/4.6, 
and the all-or-nothing opengl check it used is unfortunately locking you 
out of opengl.

But writing all the above made me think of another troubleshooting 
suggestion.  =:^)

On the middle tab, try disabling ALL INDIVIDUAL effects (even the ones 
you don't want to do without, permanently, and that you believe should 
work).  Hit apply.

Now on the advanced tab see if with all /individual/ effects disabled, 
you can successfully switch to opengl.

Hopefully that works.  If so, you can try enabling individual effects one 
at a time and see what's killing it.  But, be prepared to crash and to 
edit/rename/delete kwinrc to get back into kde, if necessary, because the 
one you just tried isn't working, and with kwin's all-or-nothing approach 
back then, there IS a fair chance that when you enable that one, you'll 
trigger a crash and won't be able to get back into kde until that bit of 
the config is removed.

> We are expecting a new Slackware version any day now which will ship
> with KDE 4.8. I am inclined to wait now until this is released after
> which I will upgrade or fresh-install. Could well be that the upgrade
> will cure the problem. If not that will be the time to devote more time
> and effort to it.

Yes.  I've seen the slackware betas mentioned on the various FLOSS sites 
I follow.  In fact, I thought the new version was actually out already, 
but it must have been just the betas I was reading about.

It's sad to be leaving the "leet" 13.37 behind, but it had to happen 
eventually, I guess. 13.37 was easy to remember, tho! =:^)

> Thanks for all your suggestions.

Based on what I know, I'm quite optimistic about the "individual effects" 
idea above, so please do try it and report back.  Of course if the new 
slack comes out first, by all means try it as it basically does the same 
thing but automatically, but the manual method's definitely worth a shot 
if the new version doesn't come out first, because I really DO think 
there's a good chance it'll work!

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