Still reproducible with kde 4.4rc1. Videocard is 945gm with latest intel drivers.

works for me.

first off, try to press shift+alt+f12 to suspend compositing (and hopefully get your desktop back)

then please notice that esp. the snow plugin is pretty "heavy" and the intel chips are rather weak ;-)
...but the combination with the cube burns my GF7600Gt as well =D

@KostyaSha:
please describe "another crazzinies" a little more deailed ;-)

1) I'm enabling snow and it works
2) I'm pressing ctrl+F11 and saw the cube with snow - it works.
3) While rotating cube goes down and i see the top half part of cube.
4) Esc ->Cube focusing on desktop. After it i saw the black screen or menus that i can't click.
5) ctrl+f11 -> I saw cube that work or half work
6) goto 4) 
Turning off compositing doesn't help. 
I don't think that this effects is "heavy". On my old desktop with mx440 cube + working mplayer on the edge of the cube were working excellent.

The _snow_ plugin /is/ heavy (but should not work on the mx440 anyway, does it?)

As turning off composition (and thus taking kwin out of the render path) doesn't clear the stage, this is (probably) a driver bug (-> what's your GPU/driver?) 
Does the content you see in 4) look like texture garbage, i.e. textures that have been used before?
What's displayed above the cube when it "goes down" in 3) (does that mean your screen is split with usable display in the lower half and junk in the upper?)

(In reply to comment #4)
> The _snow_ plugin /is/ heavy (but should not work on the mx440 anyway, does
> it?)
It uses legacy OpenGL when Shaders are not available which makes it even more heavy.

Created attachment 40050 [details]
photoshot

It's after enabling snow; enabling cube (the first time).
p.s. I guess it's mirror of real cube :) So, real cube is black.

Created attachment 40051 [details]
photoshot 2

This is after 'Esc' from cube and coming back to cube. 
Snow is working.

Created attachment 40052 [details]
photoshot 3

another screen

Created attachment 40053 [details]
photoshot 4

I can disable snow, but can't get working desktop back.
This is after returning. 
Screen doesn't updated, but under it i can click menus.
If i'm click 2times on clock or calendar widgets  screen become black.

x11-drivers/xf86-video-intel-2.9.1
x11-base/xorg-server-1.7.4
media-libs/mesa-7.7-r1
kernel 2.6.32-gentoo-r1 

P.S. ok snow wouldn't work on mx440, but don't think that snow is 'heavy' for GMA945.

(In reply to comment #10)
> P.S. ok snow wouldn't work on mx440, but don't think that snow is 'heavy' for
> GMA945.
Same problem: no shader support, so more work for CPU

(In reply to comment #11)
> Same problem: no shader support, so more work for CPU

gma950 supports fragment shader, in latest mesa even glsl is supported (however, no dynamic flow support)

(In reply to comment #11)
> Same problem: no shader support, so more work for CPU

Anyway, you can argue that intel hardware is too slow, or drivers is too buggy. But snow+cube _just works_ with compiz. Flame+cube works with compiz. Blur works with compiz (with recent drivers). So it's _possible_ on intel hardware, it's not hardware/drivers fault, it's kwin fault.

Compiz is a different window manager with a complete different design and implementation. The fact that it works with Compiz does not say anything about the kwin implementation. In fact Compiz is several years older than kwin and by that does not use GLSL but graphics assembler. I think it's the right thing to use a highlevel language and not assembler.

Comments like "works with Compiz" just annoy me and don't motivate to work on such a bug (which is impossible anyway as I do not have your hardware and cannot reproduce).

Der shaderfreie Pfad kollidiert mit dem cube. 
(schieb' einfach die shader zur seite, kwin --replace& dann snow, dann cube 
aktivieren - andersrum geht nicht, vermutlich aus gutem grund ;-)

Entweder läßt sich das lösen, oder wir deaktivieren den shaderfreien pfad 
komplett oder wir verhindern das der cube bei akiviertem screentransform 
ausgelöst wird (obwohl das vermutlich andere probleme nach sich zieht)

Ich schaue mir den shaderfreien pfad heute abend noch mal an.

Gruß,
Thomas

Am Thursday 21 January 2010 schrieb Martin Gräßlin:
> https://bugs.kde.org/show_bug.cgi?id=222872
> 
> 
> 
> 
> 
> --- Comment #14 from Martin Gräßlin <ubuntu martin-graesslin com> 
>  2010-01-21 14:36:27 --- Compiz is a different window manager with a
>  complete different design and implementation. The fact that it works with
>  Compiz does not say anything about the kwin implementation. In fact Compiz
>  is several years older than kwin and by that does not use GLSL but
>  graphics assembler. I think it's the right thing to use a highlevel
>  language and not assembler.
> 
> Comments like "works with Compiz" just annoy me and don't motivate to work
>  on such a bug (which is impossible anyway as I do not have your hardware
>  and cannot reproduce).
>

errr... i wasn't even aware that one can reply to bugs - good to know.
well, the above comment was meant to be private and now somehow is ;-P


=D

(In reply to comment #14) 
> Comments like "works with Compiz" just annoy me and don't motivate to work on
> such a bug (which is impossible anyway as I do not have your hardware and
> cannot reproduce).

That's why I'm here, I have hardware and I can test patches/provide you with debug info. How can I obtain necessary info?

=)

comment #15 actually confirms that there's a problem between the non-shader implementation of the snow effect and the cube that i can reproduce here (nvidia, i just moved the shaders out of the way to force legacy GL)

I'll try to bisect this later this day.
Please be prepared that there's a chance that due to the given plugin renderstack this collision is not resolvable (in which case the effects shall be prevented to run next to each other)

However, there's a problem with intel, as suspending compostion immediately clears the stage here (this _is_ driver internal ;-)

-- sidenote:
The gma950 series might cause further troubles, as the (level 2.0) fragment shaders appear to be rather "theoretical" and limited to _3_ texture reads.
the vertex shaders (which afaics are crucial for the snow) are implemented in the driver (i.e. on the CPU) as well as T&L (what is frankly a shame for intel ;-P )
the limited bandwidth (it's probably connected to shared RAM) should do the rest.

so please don't expect wonders on the 3D side and watch the CPU usage of effects (being "stolen" from the rest of the system)

*** Bug 226209 has been marked as a duplicate of this bug. ***

Reproduced for 4.4.0

in case you compile yourself, try to comment kdebase/workspace/kwin/effects/snow/snow.cpp

:148/149
//         else
//             glNewList( list, GL_COMPILE_AND_EXECUTE );

and : 205/206
//         else
//             glEndList();

*** Bug 230715 has been marked as a duplicate of this bug. ***

SVN commit 1124311 by luebking:

skip gl*List calls in shaderless path
BUG: 222872


 M  +2 -4      snow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1124311