Created attachment 148026 [details] the mask does not meet with the edge, producing a dark border SUMMARY This may have been reported already and I'm unsure if it's connected to bug 391956 or not. The blur mask plasma themes seem to have been shrunk by 1 pixel all-around. It's a shame because not too long ago it was (imo) nearly perfect after the corner areas stopped protruding outward so much. This is a very irritating bug if you are unfortunate enough to have to see it. I suspect that it's present on >100% scaling, but even more difficult to see. In Breeze Light, it is decently hidden. If used with the contrast effect, its appearance becomes very strong, now that the background is more saturated Except for a border around it. On dark themes with a light outline, it creates an off-putting gray border. STEPS TO REPRODUCE 1. Select Breeze Dark with background contrast on for best clarity 2. Set your wallpaper to something noisy or bright like a nature scene to better show the background, I used Cluster 3. Reveal the desktop and open a menu (e.g. Audio Volume) 4. Observe that the edges of the dialog have a dark border 5. Realize that there is no border in the svg files OBSERVED RESULT The blur mask is 1 pixel short of the edge of the dialog on the sides EXPECTED RESULT The blur mask should cleanly meet with the sides of the dialog SOFTWARE/OS VERSIONS Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.13.0-35-generic (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION On Kubuntu (KDE 5.22) it is not present. Though, the corners still extend out a bit in that version. I think somewhere between the mask fix and now something was broken. This is also present on 5.24.4 (Arch)
Created attachment 148027 [details] "gray border" effect produced when higher saturation doesn't reach edges The gray line element separating the menu from the panel is a deliberate workaround to hide the effect on that edge until the mask is fixed. It's quite a jarring bug.
Curious if any progress has been made on this one. Really don't want to be stuck with this one for another update cycle.
I've investigated this, and it's directly caused by the corner mask fix. The corners were fixed by adjusting the blurred region by -1 pixel on each side and adding a border with the same thickness. If I remove this patch, the thin borders are gone, but the corners extend out.
Darn, I could have sworn there was a grace period where it was perfect, but maybe I just hadn't noticed yet. (In reply to Silas Della Contrada from comment #3) > I've investigated this, and it's directly caused by the corner mask fix. The > corners were fixed by adjusting the blurred region by -1 pixel on each side > and adding a border with the same thickness. If I remove this patch, the > thin borders are gone, but the corners extend out. I don't really understand what you mean by "adding a border with the same thickness". Are you saying KDE shipped with changes to the blur mask such that it would be impossible for the blur to meet with the corners of the dialog? i.e. there would be a border regardless of what was specified in the svg? I'm not good with the code specifics, but to put into words what I felt making my theme's mask meet with corners cleanly (given that the mask is not anti-aliased), I felt that the way the mask was calculated just needed to be a little less aggressive with determining if a pixel was blurred or not. I remember previous themes' svgs always reduced the mask by about .5 pixels to combat this. Then, for straight edges (e.g. top, left, right, bottom) the .5 would round up to 1 and they would meet cleanly with the edges. For curved edges, less pixels would be included in the mask (because rounded down?). If the above can somehow be put into code, I think we could have a pretty decent aliased mask. The criteria for rounding up a pixel in the mask just needs to be less lenient. Perhaps .6 would be enough coverage to be considered a fully blurred pixel. However, I know firsthand this is a complicated procedure, and needs to take into account different types of rounded corners at different scalings. Obviously, I have no clue if the code lines up with what I said, but it's just a thought.
(In reply to doncbugs from comment #4) > I don't really understand what you mean by "adding a border with the same > thickness". Are you saying KDE shipped with changes to the blur mask such > that it would be impossible for the blur to meet with the corners of the > dialog? i.e. there would be a border regardless of what was specified in the > svg? Yes, the inset of the blur region is not specified by the SVG, but hard coded into the blur effect. > I'm not good with the code specifics, but to put into words what I felt > making my theme's mask meet with corners cleanly (given that the mask is not > anti-aliased), I felt that the way the mask was calculated just needed to be > a little less aggressive with determining if a pixel was blurred or not. I > remember previous themes' svgs always reduced the mask by about .5 pixels to > combat this. Then, for straight edges (e.g. top, left, right, bottom) the .5 > would round up to 1 and they would meet cleanly with the edges. For curved > edges, less pixels would be included in the mask (because rounded down?). The mask isn't anything complicated, iirc, just a rectangle that gets processed. > If the above can somehow be put into code, I think we could have a pretty > decent aliased mask. The criteria for rounding up a pixel in the mask just > needs to be less lenient. Perhaps .6 would be enough coverage to be > considered a fully blurred pixel. However, I know firsthand this is a > complicated procedure, and needs to take into account different types of > rounded corners at different scalings. Obviously, I have no clue if the > code lines up with what I said, but it's just a thought. It should be possible to implement that, but you would need to get the corner radius from the theme, treat different window types differently, apply output scaling and implement a stencil with OpenGL. Overall, more than a little bugfix, in the meantime I would recommend this plugin to you, it allows setting the corner radius manually: https://github.com/Alban-Boissard/kwin-effects-blur-respect-rounded-decorations
Thanks, I've used this one a while ago. Unfortunately, it also doesn't seem to compile on 5.24.90. I tend to use Lightly Shaders forks, if anything at all.
Created attachment 150452 [details] the mask fix under severe conditions To be absolutely clear about my position on this change: I understand that this bug is not really visible on hidpi screens and is mostly hidden in default Breeze, but I do want it to be known that it really really damages themes.
Perhaps the bulk of my frustration with this patch is the question of: if we wanted to just reduce the mask, why didn't we just change the Breeze svgs' mask to this instead of forcing every theme to always be wrong? Am I not understanding how it works? It seems that just reducing the mask in the Breeze theme's by 1px was more than enough to do this. In fact, I believe it would also get rid of the gap created between the panel and plasmoid dialogs caused by artificially shrinking the blurred area as seen in the severe case: https://bugs.kde.org/attachment.cgi?id=150452 > The corners were fixed by adjusting the blurred region by -1 pixel on each side and adding a border with the same thickness. I do want to clarify that there is no border that is added. The border exists because of the high opacity of Breeze's background.svg. For themes with reduced opacity, it just looks misaligned and text bleeds very clearly through the edges. I see now that it also affects Aurorae themes now. It's even visible on the 5.25 announcement under Tailor-made https://kde.org/announcements/plasma/5/5.25.0/
Created attachment 154035 [details] Screenshot of the panel with the outline issue This issue is very noticeable in the panel. I'm using Plasma 5.26.2 and Frameworks 5.100.
Aha, this should be fixed by https://invent.kde.org/plasma/plasma-workspace/-/commit/1abe11473bcaa282ad1b5087b8dbaab2329530de in Plasma 5.26.4.