Version: (using KDE 4.4.2) OS: Linux Installed from: Gentoo Packages The current implementation of the fade desktop effect appears to work by decreasing the opacity of all windows on desktop A from their current settings (usually 100) to 0, switching to desktop B, then increasing the opacity of all windows on desktop B from 0 to 100 (or whatever their opacity is set to). This causes a few visual anomalies that make the effect look unpolished: 1) If fading between two desktops that have maximized windows, the background wallpaper is visible when making the switch. 2) If either desktop A or desktop B have overlapping windows, you can see through the foreground windows to the background windows while making the switch. I think it would look better if the image of desktop A fades out as a whole to the image of desktop B. If the background is visible neither on desktop A or desktop B, why should it be visible when switching between them? If I cannot see through foreground windows to background windows on desktop A, why should this change when I fade to desktop B?
*** Bug 253041 has been marked as a duplicate of this bug. ***
the observation in comment #0 is not correct. The actual implementation fades out and fades in the windows at the same time. So I consider this as a worksforme.
Although it is true that desktop B is being brought up as desktop A fades, making my original comment slightly inaccurate, I feel that the stated issues remain. 1) If fading between two desktops that have maximized windows, the background wallpaper is visible when making the switch. 2) If either desktop A or desktop B have overlapping windows, you can see through the foreground windows to the background windows while making the switch. This may just be a difference in how we expect the feature to work, and I realize that setting the opacity of window regions is probably not implemented, but the "fix" I had in mind would be something like the following algorithm: - set opacity of all non-visible window regions (i.e. covered windows and overlapped regions) on both desktop A and B to 0 - set opacity of covered desktop regions to 0 (or just blank those regions out) - fade remaining visible regions from desktop A to B - reinstate desktop opacity - reinstate original opacity for all windows/window regions does this make it clearer?
> This may just be a difference in how we expect the feature to work, and I > realize that setting the opacity of window regions is probably not > implemented, but the "fix" I had in mind would be something like the > following algorithm: - set opacity of all non-visible window regions (i.e. > covered windows and overlapped regions) on both desktop A and B to 0 > - set opacity of covered desktop regions to 0 (or just blank those regions > out) - fade remaining visible regions from desktop A to B > - reinstate desktop opacity > - reinstate original opacity for all windows/window regions > > does this make it clearer? Yes that makes it more clear and I invite you to give a try to our new JavaScript effect bindings in 4.9 which makes it possible to write and distribute new effects easily :-)
What he wants requires offscreen rendering the desktop into a flat texture and fade that out. The windows do perform a crossfade (one blends in *while* the other one blends out - there is no gap) but such does not result in combined opacity of 100% To do so, one must (for opaque images) fade out one image on top of the other and the other must be initially and remain opaque (preserving exact opacity != 1.0 is possible only through shaders or dirty tricks :-) Thus changing the opacity of individual windows won't work this way ever (but obviously for the corner case of blending between two maximized opaque windows what is blending between to opaque images) -> No idea whether this can actually be done by scripting, but at least not at the current stage. (I'd however like to have a global feature effect to crossfade client regions by client requests, it could probably just provide this kind of desktop switching "by the way")