Bug 272688

Summary: Optimization of paint region in blur effect causes regression with EffectFrame
Product: [Plasma] kwin Reporter: Martin Flöser <mgraesslin>
Component: effects-variousAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: fredrik
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Martin Flöser 2011-05-07 11:32:22 UTC 
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.
Comment 1 Martin Flöser 2011-05-07 13:22:53 UTC 
I just noticed another severe regression with Aurorae. Blur is applied above the decoration
Comment 2 Fredrik Höglund 2011-05-08 13:17:50 UTC 
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.
Comment 3 Martin Flöser 2011-05-08 15:48:38 UTC 
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.
Comment 4 Thomas Lübking 2011-05-08 17:28:24 UTC 
post 6fd0c5dec59ab01ce2fa6b08696b7cba61e5ff7a apparently works here (NVIDIA)
Comment 5 Martin Flöser 2011-05-15 20:29:10 UTC 
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