Created attachment 49568 [details] Screenshot demonstrating the issue. Left: Before the frame-less window is moved. Right: After the frame-less window has been moved. Version: unspecified (using KDE 4.4.92) OS: Linux If a frame-less window is moved underneath a region marked for blurring by the KWin Blur plugin, a classical blur bleeding effect happens. The region that is marked for redrawing is too small, so the moved window will leave behind a "trail" of blurred edges. Reproducible: Always Steps to Reproduce: Disable unrelated KWin plugins, especially "Shadow" (because it interferes) and "Wobbly Windows" (because it interferes and looks horrible ;)). Only leave "Blur" enabled. Open a window that has a blurred background, for example a Plasma panel. Open another window that is frame-less, for example Google Chrome. Make the frame-less window have a permanently lower z-index than the window with the blurred background - for example by enabling "Keep below others" in the KWin window options for the window. Move the frame-less window underneath the blurred window. Actual Results: The blurred window's background will have a trail that was left behind by the moved frame-less window because of the blur bleeding effect. Expected Results: The region of the moved window marked for redrawing should be larger, so that the areas where the bleeding occurs are redrawn properly by KWin. See the screenshot for more information.
I can reproduce. Good catch
and pretty screenshot :)
i guess it's because blurring doesn't touch the exposure function to not mess up with shadows (kinda assuming they're there) -> Effect::transformWindowDamage() would actually have to use QRegion:unite() while atm it seems to only replace a rect...
This also seems to happen for regions marked for redrawal in general. For example: - Create a window that has e.g. a black square on it. - Move a blurred window over the window with the black square. A black blur "aura" appears around the black square as expected. - Make the square become white, or any other color, by using a timer or something. You will see that the black "aura" in the top window's blur remains, even though that which caused the blur "aura" has been redrawn. This is very noticeable when for example playing a video and putting a blurred window over the video. A potential fix for this would be to extend the "dirty regions" for all KWin blur redraws where a window is on top of the redrawn region by ceil(3 * sigma), where sigma is the gaussian strength parameter set to "(size - 1) / 2.5;" in kdebase/workspace/kwin/effects/blur/blurshader.cpp:78. So, in kdebase/workspace/kwin/effects/blur/blur.cpp:74 BlurEffect::updateBlurRegion, each dirty QRect needs to be expanded by "ceil(1.2 * (shader->radius() - 1))". An initial BlurEffect::expand function has been created for this purpose, but it only expands the blur region by the radius' value which isn't sufficient in order to avoid the extreme bleeding.
*** Bug 249081 has been marked as a duplicate of this bug. ***
The blur effect actually specifies that kwin should repaint the whole screen in each frame (by enabling the PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS flag in BlurEffect::paintScreen()). From your description it sounds as if some change has broken this behavior. That said, I can't reproduce the bug with today's trunk. Is it possible that this bug has been fixed, or that it only happens when a certain combination of effects are enabled?
i don't think the flag is set during "plain" moveresize ops, is it? Notice that it seems to NOT happen with a generally exposed window (like a shadowed one)
(In reply to comment #6) > The blur effect actually specifies that kwin should repaint the whole screen in > each frame (by enabling the PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS flag in > BlurEffect::paintScreen()). Does this flag also impact the way 'blur textures' are redrawn? Redrawing the whole screen using the same damaged 'blur textures' wouldn't have much of an effect... > From your description it sounds as if some change has broken this behavior. > That said, I can't reproduce the bug with today's trunk. Is it possible that > this bug has been fixed, or that it only happens when a certain combination of > effects are enabled? As I said: the bug doesn't appear when the Shadow or Wobbly Windows plugins are enabled (there are probably others that have an impact as well), because then the damage rect for the lower window's redrawn region is extended enough by those plugins that the blur textures are redrawn in a sufficiently large region anyways. Or, I should rather say: the bug doesn't manifest itself when *moving* the frameless window when the above plugins are enabled, but it still does when the lower window (frameless or not) redraws parts of its contents, regardless of which plugins are enabled. It might of course be that the bug has been fixed, but it'd need to be confirmed.
> The blur effect actually specifies that kwin should repaint the whole > screen in each frame (by enabling the > PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS flag in BlurEffect::paintScreen()). That one has to be set in the prepaint pass. And given that it almoast worked all the time I think it is not required to do slow full repaints (it really stresses the system and I did quite some improvements in trunk by ensuring that sliding popups and wobbly do not trigger full repaints). Now I also understand why I was so puzzled when you mentioned the full repaints and I had not seen them while doing my tests ;-)
Is this still the case? I can't reproduce this bug. (I use the new blur)
(In reply to Vlad Zagorodniy from comment #10) > Is this still the case? I can't reproduce this bug. (I use the new blur) I know this visual artifact just too well. This problem was caused by the "Save intermediate rendering results" option which has been already removed, so I think this is no longer an issue.
Marking as resolved fixed because of dev comment.