SYMPTOM Certain translucent windows that should have blurred background don't have it. OBSERVATION 1 Extensive googling leads to the conclusion that the common way of enabling blur on a window is to set the _KDE_NET_WM_BLUR_BEHIND_REGION property to (c32)0 on the window. This is what the popular ForceBlur KWin script does. OBSERVATION 2 As of kwin 5.16.2 and possibly earlier, those translucent windows for which the xprop command merely shows: _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 0 do NOT have blurred background. OBSERVATION 3 For those translucent windows that DO have blurred background, xprop command shows FOUR values that define a region (x,y,width,height relative to the window) instead of ONE value 0. CONJECTURE The special single value 0 of the _KDE_NET_WM_BLUR_BEHIND_REGION xprop is probably a "magic" value that is supposed to mean "entire window", but it is apparently no longer thus interpreted. This might be a regression. Operating System: Arch Linux KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0 Kernel Version: 5.1.15-arch1-1-ARCH OS Type: 64-bit Processors: 8 × AMD FX(tm)-8320 Eight-Core Processor Memory: 15,6 GiB
Using kwin_x11, not tested on wayland.
What command do you use to set _KDE_NET_WM_BLUR_BEHIND_REGION?
I use the exact same command that the Force Blur kwinscript uses: xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION 0 -id <window ID> after determining the window ID with xwininfo. Subsequent xprop indicates that the _KDE_NET_WM_BLUR_BEHIND_REGION property indeed became set on the window. However the background isn't blurred. The same happens if I add the window class to the Force blur script's list and let Force Blur set the hint. UPDATE: I just made an experiment and set the prop to rectangle (four values) using xprop. It was successfully set, but it still has no effect on most application windows. What I am trying to achieve is blurring of the background behind application windows that are semi-translucent while being dragged or resized. My syllogism here is simple: 1. This thing is semi-translucent 2. I have enabled the blur effect Therefore: I expect the background I see through this semi-translucent thing to be blurred. If this syllogism is wrong for some reason, for example if the "translucency while dragging/resizing a window" is some different kind of translucency that doesn't work with the blur effect, then this should be documented.
Errata to the above comment (because this bugtracker disallows editing comments, which is a bloody shame): I might have incorrectly generalized "0 doesn't work with most application windows" to "0, 0, <width>, <height> doesn't work with most application windows". I have tested 0 with windows of many applications, but I have only tested 0, 0, <width>, <height> with Dolphin.
Further investigation: One window for which blur DOES work is Konsole. If translucency is enabled in the konsole color style, then the terminal background is semitranslucent and the background behind it IS blurred. To eliminate the possibility that this is some kind of client-drawn or client-requested blur distinct from kwin-blur, I dragged the Konsole window, and voila - in the case of the Konsole window the background behind the kwin-drawn title bar that becomes translucent while the window is dragged IS indeed blurred. This is not the case with most application windows for which blur fails to apply. I will now focus on triangulating the key difference in xprop values that causes the blur property to be honored in the case of the Konsole window.
Incidentally, the Konsole window has _KDE_NET_WM_BLUR_BEHIND_REGION=0 and blur works. I will probably have to edit this bug's title once I determine the REAL factor that decides whether _KDE_NET_WM_BLUR_BEHIND_REGION is honored or ignored.
I performed some more experiments involving also _NET_WM_WINDOW_OPACITY, and it all quickly went down the rabbit hole of broken and conflicting functionality, including: * occurrences of unblurred AND blurred background blended together * "ghost" semitranslucent windows left after closing the windows I experimented on Further observations and conjectures: * there are apparently two distinct translucency mechanism in use; one blends window content with unblurred background, the other with blurred background * the former mechanism is used for making windows semitranslucent during dragging and resizing; this mechanism probably ignores _NET_WM_WINDOW_OPACITY and has its own settings in systemsettings * the latter mechanism is controlled by _NET_WM_WINDOW_OPACITY, and it is effectively off when _NET_WM_WINDOW_OPACITY is above 0xfeb851ea * when the _NET_WM_WINDOW_OPACITY mechanism is on, it doesn't actually use _NET_WM_WINDOW_OPACITY value for the opacity. Instead it uses an "effective" opacity value that can also be affected by the OTHER mechanism * the _NET_WM_WINDOW_OPACITY mechanism applies first, using the "effective" opacity value for blending window content over blurred background * the drag/resize mechanism applies second, using the opacity value configured in systemsettings; it seemingly treats the OUTPUT of the first mechanism as "window content", and blends THAT with UNBLURRED background * the result is that the greater translucency you set in system settings for "moved" windows, the greater the admixture of unblurred background into the final composition; at medium values you can clearly see sharp text surrounded by blur fog * sometimes blur stops working altogether for a window for no apparent reason
Please post output of qdbus org.kde.KWin /KWin supportInformation
Created attachment 121393 [details] Output of qdbus org.kde.KWin /KWin supportInformation
(In reply to Szczepan Hołyszewski from comment #0) > The special single value 0 of the _KDE_NET_WM_BLUR_BEHIND_REGION xprop is > probably a "magic" value that is supposed to mean "entire window", No setting any value should work. (In reply to Szczepan Hołyszewski from comment #3) > What I am trying to achieve is blurring of the background behind application > windows that are semi-translucent while being dragged or resized. You're most likely dragging opaque windows, this won't work. (In reply to Szczepan Hołyszewski from comment #6) > Incidentally, the Konsole window has _KDE_NET_WM_BLUR_BEHIND_REGION=0 and > blur works. Yes, because the Konsole window has alpha. In either case, there's nothing wrong with _KDE_NET_WM_BLUR_BEHIND_REGION. You should set it only for translucent clients.
If I am dragging a supposedly "opaque" window, but I am seeing the background behind it while I am dragging it, then the window is not *actually* opaque at this very moment, unless you are using a very specific and technical meaning of "opaque". At this time there are four possible situations: "can't see through", "can see through, no blur", "can see through, blur" and "can see through, blurred AND unblurred background blended together". I think there should be only two possibilities: "can't see through" and "can see through, blur" (if the blur effect is enabled, otherwise of course "can see through, no blur"). Regarding "can see through, blurred AND unblurred background blended together", after further tests I can see that the blending always occurs, and the lower the opacity (greater translucency) the more of the "dry" background is blended in. At higher but non-full opacity values the admixture of unblurred background is barely visible, but it becomes gradually more pronounced as _NET_WM_WINDOW_OPACITY goes down; the perceptual threshold is somewhere around 0xe4000000 for me, and incidentally Konsole has 0xe6666665, which is why I didn't originally see the unblurred admixture in Konsole. I'll prepare some screenshots to demonstrate the problem, and we will probably have to split this bug into several.
Created attachment 121394 [details] blur blending at _NET_WM_WINDOW_OPACITY = 0xe0000000 Unblurred background admixture not visible to the naked eye.
Created attachment 121395 [details] blur blending at _NET_WM_WINDOW_OPACITY = 0xa0000000 Admixture of unblured background becomes visible.
Created attachment 121396 [details] blur blending at _NET_WM_WINDOW_OPACITY = 0x40000000 Unblurred background dominates; with low contrast background one could be mistaken that the blurring isn't happening at all.
(In reply to Szczepan Hołyszewski from comment #11) > If I am dragging a supposedly "opaque" window, but I am seeing the > background behind it while I am dragging it, The client buffer should have alpha, though I guess we can address this issue.
RE: Screenshots Opacity of the client and opacity of the blurred background are connected.
(In reply to Vlad Zagorodniy from comment #16) > RE: Screenshots > > Opacity of the client and opacity of the blurred background are connected. Well, that's the problem right there. They shouldn't be. Background is background is background.
(In reply to Szczepan Hołyszewski from comment #17) > Well, that's the problem right there. They shouldn't be. Background is > background is background. There's no point for showing blurred background if the client is invisible. This is intentional and it's not gonna change.
(In reply to Vlad Zagorodniy from comment #18) > There's no point for showing blurred background if the client is invisible. > This is intentional and it's not gonna change. The client is far from invisible at alpha=0.25.
(In reply to Szczepan Hołyszewski from comment #19) > The client is far from invisible at alpha=0.25. How do you suggest to handle opacity animations? For example, an opacity animation will be started if you open/close Kickoff.
At the very least, please make blurred translucency JustWork™ for windows that that are normally opaque, but due to the settings of the translucency plugin become translucent while inactive or dragged / resized. I understand that _NET_WM_WINDOW_OPACITY is a hint *for* kwin to do the translucency, which also serves as a hint to perform background blur if that is enabled. However it seems that temporary translucency for inactive or moved windows does not work by setting the hint, and does not implement the "use translucency as a hint for blur" logic either. This I believe should be fixed, and I will be happy-ish to limit the settings to moderate translucency so that the admixture of unblurred background won't be visible.
(In reply to Vlad Zagorodniy from comment #20) > How do you suggest to handle opacity animations? For example, an opacity > animation will be started if you open/close Kickoff. background * (1-t/duration) + preblended_blurred_background_and_content * t/duration
In other words, admixture of unblurred background is acceptable during opacity animation when the animation is associated with showing/hiding the window.
In a perfect world I would animate the blur radius. We're not living in a perfect world.
To add a feedback data point 4 years later: I ended up no longer using any transparency or blurring. It is much more headache than wow, with all the quirks, inconsistencies and corner cutting described and analyzed in this report.