Created attachment 172515 [details] Old behavior, showing background color in blur region without being over background. *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY In the past, the blur used to sample an area outside the current window to prevent temporal artifacts. At some point this was changed and now the blur only samples areas that are in the window region. This makes the blur look bad, like it does on Windows ( because they do the same thing, only sampling what is under the actual window region ) I'm not sure why this was changed, or what led to it, but it would be awesome if we could get the old behavior back. I have attached 2 images showing the difference. STEPS TO REPRODUCE The setup is this, a terminal with a transparent BG on top of a non-transparent VSCode window. The terminal is placed overlapping to the left edge of the VSCode window, and in the old method you can see the color of the background bleeding into the terminal ( as it is transitioning from Window -> Background ). But in the new image you can see no such transition, it's only after you move the terminal past the edge of the VSCode window that you will start to see the background colors in the blur. OBSERVED RESULT Background color does not bleed into terminal blur region until window is past the edge of the non-transparent VSCode. EXPECTED RESULT Background color to show in the blur before reaching the edge or beyond the edge of the non-transparent VSCode window. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: 6.1.3 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION
Created attachment 172516 [details] New behavior showing no background color in blur region
This is an intentional change (it was part of fixing visual glitches with fractional scaling and software cursor), and reverting back to the old behavior would pose significant challenges on the technical side and likely create a whole of new problems.
a whole set*
That is very unfortunate, those artifacts are very bothersome to me.
What about the blur noise moving in the wrong direction relative to the direction the window is moved? I filed a bug about that one too, but I don't think I ever got a response. https://bugs.kde.org/show_bug.cgi?id=484726