https://bugs.kde.org/show_bug.cgi?id=409524
--- Comment #7 from Szczepan Hołyszewski <rula...@wp.pl> --- 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 -- You are receiving this mail because: You are watching all bug changes.
