Mind elaborating on "not working anymore" - do you get an error (like "could not be loaded") or do they simply not do anything or do the not work in combination (ie. sliding popups works but is not blurred) or ...

I don't get errors, both are activated but i can't see these effects, they do nothing no bluring and no sliding popups and the they do not interfere.
I wated to fil two separate bugs for each effect but i thought mabe they are related to enabling direct rendering for catalyst so it is better to group them in one report.
Sorry if i was not clear from the beginning.
I saw in another bug report that you demanded the output of "qdbus org.kde.kwin /KWin supportInformation" here is mine if this will help you :

http://paste.kde.org/673352/

Thanks, would have been the next question ;-)

run "kcmshell4 kwincompositing"
In the second tab, configure the blur effect and deactivate caching (the only checkbox)
See what happens.

To determine relation in general, please deactivate the blur effect and see whether slidingpopups start to work again.

I did everything you said nothing changed.
Now i'm using "Icon Only Task Manager" but there is no thumbnails showing when i hover the icon of an opened application despite Taskbar Thumbnails is activated.
I tried to activate the explosion effect but t get this error : explosion effect requires OpenGL 2
but my driver's OpenGL version is 3.3 (information from catalyst control center).

according to the support information you are not using OpenGL 2:
> OpenGL 2 Shaders are not used. Legacy OpenGL 1.x code path is used.

You could try to do a:
KWIN_DIRECT_GL=1 kwin --replace &

unrelated but plasma popups will likely not be used due to plasma not knowing that compositing is active: https://git.reviewboard.kde.org/r/107983/

(In reply to comment #5)
> according to the support information you are not using OpenGL 2:
> > OpenGL 2 Shaders are not used. Legacy OpenGL 1.x code path is used.
> 
> You could try to do a:
> KWIN_DIRECT_GL=1 kwin --replace &

Unfortunatly Nothing changed.

KWIN_DIRECT_GL=1 KWIN_COMPOSE=O2 kwin --replace &

either the explosion effect can be activated then or everything crashes or there's something severely broken about your installation..

Reg. the original issue:
Did you eg. try oxygen transparent or does eg the tabbox (alt+tab) blur?

If this is only about the panels there's only one problem being: plasma does not know that compositing is active

In that case: ensure compositing and the blur effect are enabled, then run:
kquitapp plasma-desktop; sleep 5; plasma-desktop

This should kill the desktop and after 5 seconds start it again. Since compositing is up at that time, plasma-desktop should notice that and activate translucency, blurring and animation for its panels.

1-kquitapp plasma-desktop; sleep 5; plasma-desktop
fixed every thing (blur, sliding popup, thumbnails) except plasmoids that blur dosen't work for them they still transparent.

2-KWIN_DIRECT_GL=1 KWIN_COMPOSE=O2 kwin --replace &
fixed explosion effect.

Now that we know what the problem is. Can i do something to fix it besides killing the desktop at every boot ?

There's always some way ;-)

To ensure kwin runs with direct rendering and OpenGL2:

add an executable shellscript to ~/.kde/env (could be ~/.kde4/env)

#!/bin/sh
export KWIN_DIRECT_GL=1
export KWIN_COMPOSE=O2

Be warned that this overrides system detection AND configuration. Don't forget you put it there, might cause trouble when you replace the hardware.

For plasma i've not tried, but guess it will be sufficient to delay the launch a bit. Place some "plasma-desktop.desktop" into ~/.kde[4]/share/autostart/

[Desktop Entry]
Exec=sleep 5; plasma-desktop
Hidden=false
Name=Plasma Desktop Workspace
OnlyShowIn=KDE;
Type=Service
X-DBUS-StartupType=wait
X-KDE-StartupNotify=false
X-KDE-autostart-phase=BaseDesktop

This will shadow the stock service and thanks to "sleep 5" wait 5 seconds before actually starting plasma in the hope that the compositor is completely up before it starts so that it will detect the compositing state "correctly" (it will eg. not notice if compositing gets suspended afterwards)

*** This bug has been marked as a duplicate of bug 179042 ***

After some testings i found out that all i need is "export KWIN_DIRECT_GL=1" to make everything work.
I removed the desktop file and "export KWIN_COMPOSE=O2" from the script.
Thank you very much for your help and good luck with the "KSelectionWatcher" bug :).

I have this bug and it still affects KDE 4.11.1. I'm running Catalyst 13.8 beta. If I disable compositing, click on something that's supposed to use the sliding popups animation (like the clock widget), click it again to close it, and then reenable compositing, I get the animation back. If I just disable and immediately reenable compositing, I'm not guaranteed to get the animation back. What's up?

(In reply to comment #12)
> I have this bug
nope ;-)

> beta. If I disable compositing, click on something that's supposed to use
> the sliding popups animation (like the clock widget), click it again to
> close it, and then reenable compositing, I get the animation back.

See?

> If I just disable and immediately reenable compositing, I'm not guaranteed 
> to get the animation back. What's up?

Timing related, i assume. Some race condition in detecting the availability of the feature (rather than compositing)
Does just "wait long enough" before re-enabling compositing do?

The effects are destroyed with the compositor and annouce their absence immediately while the compositor selection is kept for half a second to stash temprary toggles (for resets) what might confuse the client depending on how it obtains, caches and interprets availablity of compositing and effect.

See bug #179042 comment #101 and please keep this on the actual bug and not this dupe, thanks.