Can I set each of those graphicssystem options more permanently? I can run each of those commands, but I don't think it is helping -- other places where there should be transparent space around icons show up black. On the last try, I deleted everything in the cache that could be related, including

icon-cache.kcache
plasma_theme-internal-system-colors.kcache

but I'm not sure it is helping.

Does the graphicssystem show up in the GUI anywhere? OpenGL always shows for rendering. If opengl is glitchy, what can I use that isn't? I don't need any of these special desktop settings. Thanks.

The graphicssystem is NOT what you can select in the last tab of "kcmshell4 kwincompositing"
To globally set a graphicssystem put an executable file

(assuming ".kde" is your local kde dir and not .kde4)

echo -e '#!/bin/sh\nexport QT_GRAPHICSSYSTEM=native' > ~/.kde/env/qt-graphicssystem.sh
chmod 700 ~/.kde/env/qt-graphicssystem.sh

log out/in - watch the "native" string in the first command and eventually replace it by raster.

NOTICE that this will change the graphicssystem for ALL applications, what can have performance impact (some things can perform terribly with the native system, depending on your GPU/driver)
The --graphicssystem switch will still override the setting and kwin (the window manager) has a config for it (yet no GUI)
If you use xrender compositing, you WANT to use the native system, if you use some aurorae theme you will most likely be better of with raster one (and thus should use either OpenGL or rather not aurorae for best performance)

Thanks for your quick reply. If I'm not using effects, then compositing is off, right? So I don't think I need to worry about compositing at all? I don't care about themes either and would be fine with something very generic. Is AIR ok? So, given that, should I try one over the other (raster or native)? It sounds like if some things perform poorly with native then I should try raster?

Finally, and perhaps I should not ask it here: this *is* a KDE issue with my old hardware, right? It's not an openSUSE issue? If I try out gnome would there be a good chance that this problem would go away. Or, if I install an earlier version of KDE?

If I'm not using effects, then compositing is off, right?

Yes.

So I don't think I need to worry about compositing at all?

No. Todays systems are usually setup expecting compositing. Notably the X11 backing store will be turned off what makes esp. dragging windows slow and flicker. It can also cause artifacts for a lack of exposure events.
-> If you do not intend to use compositing at all - ever - you should really deactivate it and re-activate the Backing store in /etc/X11/xorg.conf

add
Option "BackingStore" "true"
to section "Device" and hope it's still supported by your driver

add
Section "Extensions"
Option "Composite" "disable"
EndSection

I don't care about themes either and would be fine with something very generic. Is AIR ok?

Since it quite relies on translucency and thus compositing, you may want to pick a theme that's more "oldschool" - check kde-look.org

So, given that, should I try one over the other (raster or native)? It sounds like if some things perform poorly with native then I should try raster?

You should use the one that doesn't break your desktop - if there's no difference, just stay with the default one (likely raster)
Things btw. /can/ perform poorly, this heavily depends on the driver. The raster engine is a software rasterizer which is just far better than the SW fallback in X11, but can naturally not keep pace with fully HW supplied native rendering - IFF - that uses HW
However since for an everlasting bug in a driver which is none of the open source ones and not the nvidia blob either, Qt always uses SW rendering for any gradient, so if gradients are not cached by the client, "native" rendering suffers from this a lot (while eg. several drivers actually *could* render gradients at the speed of OpenGL .... grrrrr ... sorry for ranting)

Finally, and perhaps I should not ask it here: this *is* a KDE issue with my old hardware, right?

We so far don't know what causes this.(unless you could spot a graphicssystem or the below or whatever)

Either the pixmap cache is garbled or Qt rendering gets confused by plasma using an ARGB window, while your (uncomposited) setup may only suit RGB ones.
In this case, try exporting "XLIB_SKIP_ARGB_VISUALS=1" in either the .kde env dir or /etc/profile (NOT in .bashrc) - disabling compositing in /etc/X11/xorg.conf should actually iirc have the same effect (but better be safe than sorry

Thank you again! This is all WAY over my head, but I'll try fiddling some more. I won't be able to get in and try any of this for a few more days, but I'll report back when I can.

for a wild guess and since you're not compositing anyway, just try

echo -e '#!/bin/sh\nexport XLIB_SKIP_ARGB_VISUALS=1' > ~/.kde/env/disable_argb.sh
chmod 700 ~/.kde/env/disable_argb.sh

(it will create a new shellscript that tells X11 to treat argb windows as rgb ones.)

then log out/in

The first thing I did when booting up this time was to try to turn on desktop effects. I checked the 'enable desktop effects at startup' and then pressed 'alt-shift-F12' and the computer froze. I had to do a hard-reboot. When it rebooted, icons were not displayed at all and the tops of windows were missing the minimize/maximize .. etc. buttons. I turned off 'enable desktop effects..' and restarted the gui (ctrl-alt-backspace) and I was back to "normal"

I do have the .kde4 folder, not the .kde folder. There is no env folder inside it.

/etc/profile already exists and tells me not to modify so I'm nervous to add that line.
I put it right within .kde4 like this

echo -e '#!/bin/sh\nexport XLIB_SKIP_ARGB_VISUALS=1' > ~/.kde4/disable_argb.sh

nope, just "mkdir ~/.kde4/env" - placing it in the .kde4 folder won't have any effect.

regardless of this, you can try xrender compositing, but do NOT want the raster graphicssystem for kwin then (the combo leads to lousy performance)

also /etc/profile will likely have told you to use profile.local or profile.d/ instead
(but the kde env path is just as fine)

could you then point the graphicssystem to be the culprit?

Ok, I've added the etc folder and am trying the different renderers.

Perhaps I should have mentioned this earlier as I'm now realizing it may be related. When I first did this install (completely clean install from a wiped disk) back in January, all the windows were locked in the upper left corner, and no icons were visible on the upper bar of each window. Google searches led me to compiz and installing compiz solved that problem. So ... fyi ... I have compiz installed if that matters.

thow wrote:So ... fyi ... I have compiz installed if that matters.

are you also using Compiz or is it just installed?

mgraesslin wrote:are you also using Compiz or is it just installed?

Stupid question, but, how do I figure that out?

(edit) Let me rephrase that: when I installed it my desktop problems with the windows being locked in the upper left corner went away. I'm pretty sure that was not coincidence. But, otherwise, I'm not actively using it for changing any desktop settings. So, otherwise, I don't know how to tell whether I'm using it or not.

So this is bizarre. The computer went into screen-save mode (blank screen) and many transparent areas went black after reviving. I thought I might have an easily replicable test. But, after setting it to 1 minute and waiting using various compositors .. nothing.

But, I think I am successfully changing graphics systems among native, raster, and opengl. OpenGL *does* behave differently than the others and does produce some funky rendering. Right now, I can't distinguish between the other two.

But now, however, whenever I hover over a desktop icon the space around it appears white ... no matter what graphics system I use. See this image

http://tinypic.com/r/ac3igh/5

This does not happen for the icons in the 'folder view' in the center of my desktop, only those other ones.

I deleted the disable_argb.sh file in case that was related. No change.

I realized I'm not providing much to go on here. Arrggh.

thow wrote:

mgraesslin wrote:are you also using Compiz or is it just installed?

Stupid question, but, how do I figure that out?

ps -Af | grep -v 'grep' | grep -E '(compiz|kwin)'

thow wrote:(edit) Let me rephrase that: when I installed it my desktop problems with the windows being locked in the upper left corner went away.

if they had no decoration and could not be moved at all (eg. by alt+tab) that means there was no WM (installed / running) or kwin crashed over and over again (while not being an issue with the compositor, which would just have been disabled then)

In case you're running compiz, try to install sth. called "openbox" and replace compiz by it*, clear the cache and check whether the issue remains.

* either by removing the package or by calling "openbox --replace&"
similarly "kwin --replace&" would replace the current WM with kwin. if it crashes, you should get a bug dialog and file a bug (the easy way of submitting however atm. does not work for changes in http://bugs.kde.org, so just go there, open a new bug for kwin and simply post the backtrace found in "developer information" of the bug dialog)

Thank you!

luebking wrote:ps -Af | grep -v 'grep' | grep -E '(compiz|kwin)'

output is:

tim 10208 10206 0 09:06 ? 00:00:14 kwin -session 1015efed4e2000133129687000000078930000_1331301857_378782


so that means I am using kwin, I take it.

And yes, there was nothing I could do to move the windows and they had no decorations.

thow wrote:But, I think I am successfully changing graphics systems among native, raster, and opengl. OpenGL *does* behave differently than the others and does produce some funky rendering. Right now, I can't distinguish between the other two.

But now, however, whenever I hover over a desktop icon the space around it appears white ... no matter what graphics system I use.

Drat! I wasn't clearing the cache between changes. I need to work on this a bit more. Sorry.