Bug 245388

Summary: Shading windows does not reset Blur_Behind regions
Product: [Plasma] kwin Reporter: Hugo Pereira Da Costa <hugo.pereira.da.costa>
Component: compositingAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: hugo.pereira.da.costa
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Mandriva RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: screenshot of the issue

Description Hugo Pereira Da Costa 2010-07-22 03:20:33 UTC 
Created attachment 49380 [details]
screenshot of the issue

Version:           unspecified (using Devel) 
OS:                Linux

When shading a window using a style that supports ARGB and BLUR_BEHIND, the BLUR_BEHIND_REGION still appears on the screen, though the window content is (naturally) hidden.

I tried fix in the style by clearing all Blur_Behind region in Hide event, but unfortunately, the hide event is passed to the widget after the shading has occured, so that the blur behind region is still visible, at least until the next screen repaint.


Reproducible: Always

Steps to Reproduce:
use either bespin or experimental oxygen (http://kde-look.org/content/show.php/oxygen-transparent?content=127752) with transparency + blur enabled, open an application, shade the window, 

Actual Results:  
Nice blurred desktop on the area where the window was

Expected Results:  
Ideally, whatever Blur_behind_region is set for a window should just be ignored when the window is shaded, and the proper areas repaint triggered after shading (they already are, I presume).
Comment 1 Hugo Pereira Da Costa 2010-07-22 03:31:47 UTC 
Note: this is using kde4.5rc2 mandriva rpms, courtesy from Neoclust, with experimental oxygen.
Comment 2 Martin Flöser 2010-07-22 06:52:49 UTC 
In case you want to try:
add a virtual boolean isShade() to EffectWindow (seems not to exist) and pass 
it the value of the matching client method. And change blur effect to not blur 
shaded windows.
Comment 3 Hugo Pereira Da Costa 2010-07-22 07:06:21 UTC 
@Martin
mmm. What about BC ? (I'm always a bit scared about things like "class KWIN_EXPORT EffectWindow")
Comment 4 Hugo Pereira Da Costa 2010-07-22 07:55:05 UTC 
@martin, again

From what I could test, what you suggest has the same effect of what I tried inside the style (which is good already: I'd remove the code from the style): the blur region is still there, immediately after the shade, but dissapears as soon as you triggers anything that repaints the desktop. (like: changing the active window). 

Somehow it seems the shade action itself does not trigger the proper repaint of the blur effect. I might have some time to look into it more tomorrow (like in e.g. client::setShade).
Comment 5 Martin Flöser 2010-07-22 19:58:41 UTC 
> --- Comment #3 from Hugo Pereira Da Costa <hugo pereira free fr> 
> 2010-07-22 07:06:21 --- @Martin
> mmm. What about BC ? (I'm always a bit scared about things like "class
> KWIN_EXPORT EffectWindow")
No problem, we don't provide BC and I broke it several times this week (and I 
am going to continue to break it)
Comment 6 Philipp Knechtges 2011-10-15 14:33:17 UTC 
Git commit 70893bbcd1b4657ba323f050658a8c6b27f7977e by Philipp Knechtges.
Committed on 15/10/2011 at 16:19.
Pushed by knechtges into branch 'master'.

kwin: fixing blur for shaded windows

If a window is "rolled" up we should not blur the specific regions.

CCBUG: 245388

M  +3    -5    kwin/effects/blur/blur.cpp

http://commits.kde.org/kde-workspace/70893bbcd1b4657ba323f050658a8c6b27f7977e