Version: unspecified (using Devel) OS: Linux The optimization with git commit a6bdff71b42a9cc241a92cf326ab6984ed041b92 is causing a regression visible in BoxSwitch effect. The background of the EffectFrame is flickering on Alt+Tab or mouse over and the blur is not reliable applied. I think the issue is caused as the EffectFrames' blur regions are unknown in the prePaintScreen pass. This would require quite some changes to the EffectFrame, which could make sense for 4.8 as a longterm solution by integrating the frames into the stacking order. In the shortterm it should be possible to just ensure that the area is blurred (we actually know that the EffectFrame is on top of all windows). Reproducible: Always Steps to Reproduce: just use boxswitch and tab or move mouse around Actual Results: flickering and no reliable blurred background of box Expected Results: box should be blurred and not flicker GLES used, though should be of no relevance.
I just noticed another severe regression with Aurorae. Blur is applied above the decoration
This is a side effect of having objects in the scene that are not actually in the scene graph. All objects in the scene should inherit a common base class so they can be inserted in the same graph and returned by stackingOrder(). With this design there would be no need for hacks like paintEffectFrame(), since it doesn't really matter to the effects if they are painting a window or something else. The fade effect would be able to fade EffectFrames as if they were EffectWindows etc. That said, I can't reproduce the problems you are describing with the GLX backend. If the repainted region isn't large enough the blurred area might look wrong near the borders of the EffectFrame, but it shouldn't flicker. Anything that uses an EffectFrame will have to ensure that a large enough area of the screen is repainted though. At least 16 pixels in all directions around the frame. I've pushed a commit that might fix the problem you are seeing with the window frames, but I can't reproduce that problem here.
I agree on the stacking order part and think we should redesign this for 4.8. Your fixes did not improve the situation of the two issues, but it's possible that it is just on GLES. I will try with my NVIDIA system as well.
post 6fd0c5dec59ab01ce2fa6b08696b7cba61e5ff7a apparently works here (NVIDIA)
Git commit 304ca105d085c950cbdcddac1f896676f186055c by Martin Gräßlin. Committed on 15/05/2011 at 20:26. Pushed by graesslin into branch 'master'. Do full repaints on window damage in boxswitch with GLES Due to changes in the blur effect, the EffectFrame was flickering with GLES. This can be worked around by doing full repaints whenever a window is damagded while boxswitch is active with GLES. The problem only occurs with the GLES backend due to the way how the buffers are swapped. BUG: 272688 M +4 -0 kwin/effects/boxswitch/boxswitch.cpp http://commits.kde.org/kde-workspace/304ca105d085c950cbdcddac1f896676f186055c