Bug 395725

Moving to Aurorae component because the blur effect has nothing to do with this.

Aurorae decoration plugin says to blur background for all decoration themes so the blur effect does it. See https://phabricator.kde.org/source/kwin/browse/master/plugins/kdecorations/aurorae/src/aurorae.json$17

does this problem exist with all themes, or just the one you posted the screenshot from?

On all aurorae themes with rounded corners.
It's good looking on light background.
For example:
https://www.opendesktop.org/p/1237919/

Created attachment 113512 [details]
Quasi Deepin Aurorae Theme (enabled blur)

Created attachment 113513 [details]
Quasi Deepin Aurorae Theme (disabled blur)

This happened on Yakuake shadows skin too.

Created attachment 113584 [details]
yakuake skin (shadows)

Created attachment 114261 [details]
Window decoration vs plasma widget

I can confirm this, it happens to all window docorations (including breeze) and kvantum context menus and tooltips. All that have some form of rounded corners, which are not few.
It's like kwin draw the blur in a rectangle and don't consider the window corner geometry.
Only plasma panel elements are not affected.

(In reply to Lucas from comment #8)
> Created attachment 114261 [details]
> I can confirm this, it happens to all window docorations (including breeze)
AFAIK, the Breeze decoration theme doesn't have blur.

> and kvantum context menus and tooltips. All that have some form of rounded
> corners, which are not few.
> It's like kwin draw the blur in a rectangle and don't consider the window
> corner geometry.
On compositor side, we can't discard blurred pixels where window is fully
transparent (what if the window has fully transparent background, e.g. Konsole
with 100% transparency).

Instead, Kvantum should upload rounded blur region.

This is indeed a "bug"/missing feature in KDecoration. The decoration plugin should provide the Blur effect what regions to blur.

s/provide/tell/

The problem is deeper: Aurorae themes don't provide such information, so improving KDecoration unfortunately won't help.

(In reply to Martin Flöser from comment #12)
> The problem is deeper: Aurorae themes don't provide such information, so
> improving KDecoration unfortunately won't help.

but it would a step in right direction, right?

s/would/would be/

(In reply to Vlad Zagorodniy from comment #9)
> (In reply to Lucas from comment #8)
> > Created attachment 114261 [details]
> > I can confirm this, it happens to all window docorations (including breeze)
> AFAIK, the Breeze decoration theme doesn't have blur.
> 
> > and kvantum context menus and tooltips. All that have some form of rounded
> > corners, which are not few.
> > It's like kwin draw the blur in a rectangle and don't consider the window
> > corner geometry.
> On compositor side, we can't discard blurred pixels where window is fully
> transparent (what if the window has fully transparent background, e.g.
> Konsole
> with 100% transparency).
> 
> Instead, Kvantum should upload rounded blur region.

I was referring more specifically to breeze forks, like breezeblurred and sierrabreeze.
So, it's possible for the theme specify which areas to apply the blur? Like creating a mask for the effect?

(In reply to Vlad Zagorodniy from comment #13)
> (In reply to Martin Flöser from comment #12)
> > The problem is deeper: Aurorae themes don't provide such information, so
> > improving KDecoration unfortunately won't help.
> 
> but it would a step in right direction, right?

For real decos like breeze: yes. For Aurorae unfortunately not. My experience was that themes don't get updated when we introduced improvements. Up to the point that I gave up on adding improvements.

So, assuming I am using Breeze, is there any way to avoid this problem?
I am fine with patching it myself etc. I just need a general direction to go into. This bug has driving me crazy; it is what keeps Plasma from being by the "without a doubt standard DE" for me.

I am facing this issue with every other window decoration (only when blur is enabled) other than Breeze.

Does anyone know a way to work around this bug or how it may be resolved? It affects SierraBreezeEnhanced among many other window decorations, https://github.com/kupiqu/SierraBreezeEnhanced/issues/24

I will comment on this rather than open a new issue (what I was about to do).
This should be moved to kwin/decorations. I am currently working on a fork of breeze and encountered the mechanics for this to be the following:
People will usually triggere this when using transparencies with rounded corners. The desktop blur effect system plugin also highlights this but it's actually not it's fault. It just makes visible how your window is being drawn by Qt. Yes breeze does have support for blur (although not being accessible by any configuration, so you might debate about what is "support" I guess), because it does not at all depend on the decoration. It depends on the desktop effect plugin. Any Qt drawn opacity below 1.0 will get the blur from the plugin applied if it is activated. Breeze even has the compatibility boolean in its JSON file set to false. But this is not important to the issue.

The QDecoration Class (which is archived by Qt since 4.8 and even back then was flagged for _embedded_ Linux) is used to paint the foreground chunk of the window decorations in breeze. It is the top level widget window. Qt is explicit about this: 

From https://doc.qt.io/archives/qt-4.8/qwidget.html#autoFillBackground-prop
[...]
autoFillBackground : bool
This property holds whether the widget background is filled automatically.
If enabled, this property will cause Qt to fill the background of the widget before invoking the paint event. The color used is defined by the QPalette::Window color role from the widget's palette.

In addition, Windows are always filled with QPalette::Window, unless the WA_OpaquePaintEvent or WA_NoSystemBackground attributes are set.
This property cannot be turned off (i.e., set to false) if a widget's parent has a static gradient for its background.
[...]

Emphasis on the second last sentence.
Further you will find that the first painting action for a non-special (shaded etc.) situation for breeze is this:
painter->fillRect(rect(), Qt::transparent);
So according to the Qt documentation our top level QRect from the Decoration Class is now drawn with a transparent QtGlobalColor. If you delete this line it will default to the same transparent color.
You can change this to Qt::red or any other prominent color to clearly make this visible. After changing the color of the top level rectangle you can see that it is always drawn as simple QRect, be it with XRender or OpenGL. If you apply transparency in this situation you can clearly appreciate the underlying top level rectangle.
The blur effect visually reinforces this construction by applying the blur to the transparent top level QRect. Now suddenly it is not just transparent anymore.

I see two possible approaches to this which I'm not able to implement myself:
1. Make the top level widget a rounded rectangle. This seems to be difficult to me as Qt does not provide a direct approach for this. The QRect Class has no such implementation.
2. Find a way to not have the top level widget be filled. The mentioned article may be of help.

Here are some images for the described behavior.
REFER TO PREVIOUS POST!
https://imgur.com/r0gQuaX
https://imgur.com/fGqZAql
https://imgur.com/AJ0pHCS

*** Bug 410822 has been marked as a duplicate of this bug. ***

After some debugging it seems the easiest way to move forward past these problems would be to add support in KDecoration2::Decoration so that it can calculate the shape of a window. Then these lines could be modified in the blur plugin to have an additional mask afterwards:

https://github.com/KDE/kwin/blob/e8fe3f2fb7195fe562a073d1a78eb05d74670cfd/effects/blur/blur.cpp#L389-L413

Basically, it would end up having something like this near the end of it:

    if (AbstractClient *c = dynamic_cast< AbstractClient * > (toplevel)) {
      if (KDecoration2::Decoration *d = c->decoration()) {
        if (d->hasWindowShape()) {
          region &= d->windowShape(w);
        }
      }
    }

"hasWindowShape" and "windowShape" are just example names, but would be the new methods added to KDecoration2::Decoration. The default implementation would be for hasWindowShape() to return false and the default implementation for windowshape() would be to return the rectangle of the window. However, a decoration could opt to return a QRegion from windowShape() that better describes the shape of the window with it's decorations - such as a rectangle with rounded corners.

If this can already be done with the existing KWin frameworks I am interested to know how.

Thanks

Any update on this? It affects lots of themes.

 I have Manjaro KDE :
Operating System: Manjaro Linux 
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.68.0
Qt Version: 5.14.2
Kernel Version: 5.6.3-2-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i7-4500U CPU @ 1.80GHz
Memory: 7.7 GiB of RAM

I can confirm this problem is present and it happens because of the "Blur Strength" component of the blur effect:

Many new themes have a blur in the panel which I really hate, therefor I try to reduce it as much as possible, the best way I found is to increase the value of the "Blur Strength" component of the blur effect, however this causes the rounded corners of a theme to have a pointy non-transparent effect it the corners of the aurorae theme is rounded.

By reducing the value of "blur strength" the effect is reduced but also the the blured components becomes more transparent

It's a major issue, very annoying. When it will get fixed???

This bug also seems to affect latte dock shadows with a blurred background.

Same issue, KUBUNTU 20.04/Kvantum blur enabled. When using compositor OpenGL.

Can anyone help us with this?

Having this problem too with the Moe theme and Moe Kvantum. Specs are-
Operating System: Manjaro Linux
KDE Plasma Version: 5.19.3
KDE Frameworks Version: 5.72.0
Qt Version: 5.15.0
Kernel Version: 5.7.9-1-MANJARO
OS Type: 64-bit
Processors: 8 × Intel® Core™ i5-8265U CPU @ 1.60GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

*** Bug 425966 has been marked as a duplicate of this bug. ***

*** Bug 427497 has been marked as a duplicate of this bug. ***

More and more themes with rounded aurorae components gets released so the issue becomes more visible and super annoying.
For example, WhiteSur family of themes is providing with strong, rounded corners on all window sizes, which changes the feel of the whole OS. I really like it. Its  biggest pain point is these corners. They're driving me crazy but I'm not willing to disable blur either.

We can't relay only on Breeze and its forks. It's too limiting. This has to be fixed and from what I see, there are some ideas how it could be done. Hopefully this becomes a real project to do on some upcoming Plasma release. So far this is only an old bug report that hangs here indefinitely, which is sad.

Hoping some folks will look into this. It seriously impact so many new projects like Lightly and many kvantum based themes.

Where would be the right place to make this kind of change? My proposal would require modifying KDecoration2::Decoration, is that something that can happen?

Vlad, do you have any suggestions?

This issue does not exist on "Oxygen" Window Decoration theme. Actually Oxygen theme looks super stable compare to others (eg. breeze). May be there is something special what can be implemented in breeze too?

(In reply to llocnex from comment #36)
> This issue does not exist on "Oxygen" Window Decoration theme.

I would want to add that, at least for me right now, the blur on titlebar does not exist anymore. While good for opaque titlebars, it is annoying for transparent titlebars, not only aurorae but Breeze forks as well, like Lightly, Breeze Enhanced and others. Is this intentional or am I the only one experiencing this?

(In reply to llocnex from comment #36)
> This issue does not exist on "Oxygen" Window Decoration theme. Actually
> Oxygen theme looks super stable compare to others (eg. breeze). May be there
> is something special what can be implemented in breeze too?

Oxygen just has blur disabled in its .json file, so not a solution.

(In reply to Paul McAuley from comment #39)
> (In reply to llocnex from comment #36)
> > This issue does not exist on "Oxygen" Window Decoration theme. Actually
> > Oxygen theme looks super stable compare to others (eg. breeze). May be there
> > is something special what can be implemented in breeze too?
> 
> Oxygen just has blur disabled in its .json file, so not a solution.

I didn't know that was a thing. Just curious, how do I change that? Assuming it also work on Breeze for being based on Oxygen

(In reply to ryu.ketsueki from comment #40)
> (In reply to Paul McAuley from comment #39)
> > (In reply to llocnex from comment #36)
> > > This issue does not exist on "Oxygen" Window Decoration theme. Actually
> > > Oxygen theme looks super stable compare to others (eg. breeze). May be there
> > > is something special what can be implemented in breeze too?
> > 
> > Oxygen just has blur disabled in its .json file, so not a solution.
> 
> I didn't know that was a thing. Just curious, how do I change that? Assuming
> it also work on Breeze for being based on Oxygen

Breeze doesn't have this bug because Breeze also has blur disabled in its breeze.json file. It's the Breeze forks with blur enabled in their .json, and all Aurorae decorations (blur enabled in aurorae.json) which are affected.

To change the .json you need to edit the source code of the decoration and recompile.

(In reply to Paul McAuley from comment #41)
> Breeze doesn't have this bug because Breeze also has blur disabled in its
> breeze.json file. It's the Breeze forks with blur enabled in their .json,
> and all Aurorae decorations (blur enabled in aurorae.json) which are
> affected.
> 
> To change the .json you need to edit the source code of the decoration and
> recompile.

Then I am experiencing a bug with Breeze and all the forks. None of them have blur working on my end and at least Lightly, the one I compiled from source, have Blur enabled. Should I open another bug report for this specific one?

(In reply to ryu.ketsueki from comment #38)
> I would want to add that, at least for me right now, the blur on titlebar
> does not exist anymore. While good for opaque titlebars, it is annoying for
> transparent titlebars, not only aurorae but Breeze forks as well, like
> Lightly, Breeze Enhanced and others. Is this intentional or am I the only
> one experiencing this?

Are you using a build of kwin from the git master or KDE Neon Unstable? I am also experiencing blur not working at all on these builds and so filed bug 435862 .

As for this bug, I was investigating how to fix it but can't try anything out due to bug 435862 as can't test.

It seems that the problem is not with the code of the blur effect itself (as Vlad has already pointed out), rather that the following properties are not being set by the kwin client and in an interface to your decoration plugin in kdecoration:

EffectWindow (libkwineffects/kwineffects.h)

/**
* Whether the window has an own shape
*/
Q_PROPERTY(bool shaped READ hasOwnShape)
/**
* The Window's shape
*/
Q_PROPERTY(QRegion shape READ shape)


I have no idea if a QRegion is an efficient way to clip (in my ClassikStyles decoration ( https://github.com/paulmcauley/classikstyles/tree/paulmcauley/cornerblurfix/ ) I already use QPainterPaths to clip the corners of my buttons and find QPainterPaths easier to work with and to construct rounded rectangles or any shape you want). I have preliminarily added a windowShape() method to my decoration which converts a QPainterPath of my window shape to a FillPolygon, then to a Polygon, then to a QRegion (!), a shared pointer to which is then returned.

I was then investigating how to glue these two together through the kdecoration and the kwin client classes, but can't continue for now due to bug 435862 preventing testing.

Once we have binary decoration plugins working by being able to return a windowShape(), this functionality could be easily added to Aurorae decorations for the limited case of rounded rectangles if the Aurorae rc files were extended to have a CornerRadius property.

*** Bug 418276 has been marked as a duplicate of this bug. ***

not an expert here just wondering about there just being an easy fix perhaps:

Since blur is not part of the themes or window-decorations and if a user customizes his desktop with any combination of themes, to achive blur he will also have to go into the effects to activate it. Now here is my thaught:

Why not just make the blur corner radius configurable in the blur effect settings. yes then it is just manual but users configure the blur str aso anyways when they customize their desktop. All this automatic detection stuff is maybe just unneccessary.

Just a thaught from a different perspective after reading about this issue alot: take it as you wish, not an expert here on the technical side, just dont underestimate the KDE powerusers that are affected by this. they know how to configure themes and alot of stuff why not this too.

Not an expert here either, but what happened to masks? The Aurorae documentation lists them and I assumed they worked the same way masks work in Plasma Styles. However, when masks are used and compositing is turned off, it seems clear that they are no longer functioning-there is only a black rectangle with full corners.

https://techbase.kde.org/User:Mgraesslin/Aurorae#Aurorae_Designer

Window Decoration > decoration-opaque

I managed to work around this problem in my fork of Luwx's LightlyShaders in this commit:
https://github.com/a-parhom/LightlyShaders/commit/5e08eb3439dad848bcf01f393f3d3af0bcd61270

The fork is based on the new DeformEffect class from Plasma 5.23. My approach has a drawback, because it shrinks the shadow of a window a little bit. The bigger is your corner radius the more it shrinks the shadow, because now there is no such thing as WindowQuadType so no way to decouple the shadows from the window frame. So I have to move the shadows to the center of window in order to hide cut out corners. This approach also works with client-side decoration shadows, like Firefox or Chrome (without system decoration). 

Not a perfect solution, but no more annoying blur bug. Maybe someone can make a better solution based on this approach.

(In reply to Kristopher Ives from comment #19)
> Does anyone know a way to work around this bug or how it may be resolved? It
> affects SierraBreezeEnhanced among many other window decorations,
> https://github.com/kupiqu/SierraBreezeEnhanced/issues/24

Somehow, I got the dreaded "korners" after a recent upgrade, despite not having them before. The workaround that worked for me:

1. Go to "System Settings > Workspace Behavior > Desktop Effects"
2. Disable "Background contrast" checkbox
3. Click the "Apply" button

Some people say that they also had to disable "Blur" (in the same section of "System Settings"), but for me, the "korners" have gone away even with "Blur" enabled. I'm using theme "Breeze Dark" for everything.

What if devs make it a theme attribute so that the theme tells the compositor to discard blurred pixels outside a rectange with rounded corners? So that the theme makers have to write the radius of the corners in their CSS table or whatever is used to create themes?
P.S. Hello to Ukrainians ;)

(In reply to folderkillered from comment #50)
> What if devs make it a theme attribute so that the theme tells the
> compositor to discard blurred pixels outside a rectange with rounded
> corners? So that the theme makers have to write the radius of the corners in
> their CSS table or whatever is used to create themes?
> P.S. Hello to Ukrainians ;)

The devs don't care about this bug. Like they don't care about messed up margins after Plasma 5.21, because of that icons in the top panel are tiny.

I've implemented a different approach in my LigtlyShaders fork. Now it kind of "interpolates" the shadows in the cut out corners. Although still a hacky solution, but now it does not shrink the shadows and does not use DeformEffect, which fixes some bugs related with previous approach.

(In reply to andriy.parhomenko from comment #50)

It would be better to see Aurorae have shadow, window, and blur mask like the Plasma theme engine uses. With that way, special corners like in Rounded and Lyra could be supported by the themer.

For now, I think your shader is a great solution. It is very nice to not have korners, even if it means a performance hit.

(In reply to tomas from comment #51)

Are you talking about the margins separator plasmoid?


For anyone reading this bug, disabling background contrast can hide the bug better. Disabling blur prevents the bug completely (if compositing is on). Adding a corner radius would only support themes with basic round corners. Lyra, Marshmallow, and Rounded all have tricky shapes that would not work well.

(In reply to doncbugs from comment #53)

No, I'm talking about Margins in the panel. For example Plasma 5.18 has perfect icon size in the top panel (Application Menu Bar) while since Plasma 5.21 Icon size in Panel is small. You can fix it by editing theme SVG file. But it changes Margins for everything. Users should be able to set Margins for every Panel like they can set height.

(In reply to Tomas from comment #54)
What's your bug report's id? I don't think I've had that problem.

A just make a fork (as an independent effect) of the blur effect that solve this issue in a very simple way:

The blur effect:
- calculate the region to blur as a QRegion.
- render the blur region on the screen
- render the window on the screen

So, in the "blurRegion" function, if needed, I remove the rounded shapes of the corners from the QRegion before the blur occurs. (Unless the windows is maximized)
The rest of the code is exactly the original one, so there is no bad interaction between the patch and the shadows. 
You can chose the radius of the removed region in the effect options. That works with all the decorations I have tested.
The effect is provided as an independent effect, that you can install it alongside the default blur effect.

You can find the effect here :
https://github.com/Alban-Boissard/kwin-effects-blur-respect-rounded-decorations

If I get good feedback, I can propose a patch upstream.

Yes please do consider submitting your fix upstream!

I don't think shaders are the right approach, but we could drop support for any themes that aren't just regular rounded rectangles. That could get the patch accepted. https://www.pling.com/p/1002681

I agree this patch is not a perfect solution, and I agree with Paul McAuley (in comment #44) and  Kristopher Ives (in comment#23) about a possible better solution.

Note that to solve the issue, the effect just crop the corners of the QRegion that define the "region to blur", it not involve hacky shader tricks.

I'm a beginner en C++ and with the kde code base, but  
So a possible pattern could be :
- Add three property for the Kdecoration :
"hasroundedCorners" for Kdecoration, default to flase if not set.
-

(Can't remove or edit the previous unfinished comment)
I agree, this patch is not a perfect solution, and I agree with Paul McAuley (in comment #44) and  Kristopher Ives (in comment#23) about a possible better solution.

Note that to solve the issue, the effect subtracts four rounded QRegion to the corners of the QRegion that define the "region to blur" ; it not involve hacky shader tricks.

I'm a beginner with C++ and the kde code base, but looking at the code I think a possible pattern could be :

- Add four properties for the Kdecoration :
   - hasRoundedCorners, default to false.
   - topRoundedCornersRadius, default to 0
   - bottomRoundedCornersRadius, default to 0
   - hasCustomShape, default to false
This could be set in the .json or kcfg file of the Kdecoration, and programmatically changed if needed.

- In the blur effect.
  1) Check if the window have a CustomShape (provided as a QRegion). If yes, use it.
  2) If not, check if the window declares roundedCorners. If yes, remove the corners from the QRegion to be blurred, using the radii provided by the kdecoration.
  3) If not, check if the user has set some rounded corners radii directly via the effect ui. If yes, use it. (for compatibility with old deco)
  4) If not, do nothing more than the current effect.
 
In the effect ui,  the corners radii parameters could be moved in another tab and we can add a check button like :
"Force to respect rounded decorations corners. Only usefull for decorations that don't provide the information."

I hope it makes sens.

I will be very busy for the 10 next days, but after that I can submit a fix for point 3). (If somebody as time to do that before me, he's welcome !)
Adding the ability to manually set the corners radii seems to not compromise the possibility to do it directly in the deco later.

Does the KDecoration have the ability to clip window content in the bottom corners region? As far as I know, that could only be achieved with shaders. Please tell me, if I'm wrong. I'm also intrested in fixing this the right way, not through the hacks with shaders, and maybe I could try to help, but I'm not sure if that is possible.

(In reply to andriy.parhomenko from comment #61)

I don't know... To clip window content,  a shader is maybe the right thing to do. I only spoke about shaders in response to  #Comment 58.

We have the pixmap of the decoration, we can do `QRegion(pixmap.mask())` to turn that into a region. That's how the client side works where plasma has a rounded panel.

It isn't super fast, so we can't afford to do it every frame. We would need to cache it in the decoration and invalidate it whenever a margin changes. 

That approach will be backwards compatible with all existing themes, doesn't require the horrible user facing config and should be relatively simple.

RE: shaders.

A shader on it's own still needs the data from somewhere. One needs to modify the fragment shader that takes two textures, one to paint and one to use as as mask.

For one texture, that's ridiculously easy.

But for kwin and here it's much harder. The blur has one geometry, our paintWindow contains 4 decos, 4 shadows, and the contents each with their own geometry. Blur would need to position all of these which means recreating a the full vertex buffer that we use for window painting!  I don't think that's realistic.

Hopefully the above will mean you won't need to.

*** Bug 436595 has been marked as a duplicate of this bug. ***

*** Bug 448507 has been marked as a duplicate of this bug. ***

work on this: https://invent.kde.org/plasma/kwin/-/merge_requests/1961

(In reply to Michail Vourlakos from comment #67)
> work on this: https://invent.kde.org/plasma/kwin/-/merge_requests/1961

What if blur happens only under pixels which have an alpha value? I am no programmer, but I think this should be possible.

(In reply to folderkillered from comment #68)
> (In reply to Michail Vourlakos from comment #67)
> > work on this: https://invent.kde.org/plasma/kwin/-/merge_requests/1961
> 
> What if blur happens only under pixels which have an alpha value? I am no
> programmer, but I think this should be possible.

In Aurorae themes, there is no separation of window and shadow. Both SVG elements are part of the same frame. In my attached screenshot, the left shows a theme. There are details present with varying opacities, so going by alpha would blur the shadow and outlines as well, regardless of whether a designer wanted that or not.

Someone correct me if I'm wrong, but I think the blur effect does not support alpha. In any plasma theme with low opacity, the 'pixel art' corners of the plasmoids can be visible. The right side of the screenshot shows how the blur mask is not anti-aliased. This problem was somewhat fixed when a bug in the mask calculation was fixed, but certain corner shapes and radii can still make it visible. Clever hiding by the designer is usually necessary to avoid seeing the blur region bleed outside of a corner.

Created attachment 146238 [details]
Aurorae theme + Blurred Area of a Plasma Theme

I saw a fork of the blur effect on github that aims to be a solution for this problem. It appears to shape the effect itself instead of using a shader and only works on window decorations and there are clear limitations. I didn't analyze it too deeply but it may be into something.

Link: https://github.com/Alban-Boissard/kwin-effects-blur-respect-rounded-decorations

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdecoration/-/merge_requests/17

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1974

Git commit fb56349603067463ffef1ea158fd7a6c10d26e0f by Michail Vourlakos.
Committed on 09/02/2022 at 20:41.
Pushed by mvourlakos into branch 'master'.

decoration:add blurregion property

--every decoration can now set a blurred region that
is totally related to it. 

M  +2    -0    src/decoration.cpp
M  +7    -0    src/decoration.h
M  +1    -0    src/decoration_p.h

https://invent.kde.org/plasma/kdecoration/commit/fb56349603067463ffef1ea158fd7a6c10d26e0f

Git commit bc145b614c9f1c7594b01d88a2dfbebead50d489 by Michail Vourlakos.
Committed on 09/02/2022 at 21:00.
Pushed by mvourlakos into branch 'master'.

support kdecoration2 blurregion

--use kdecoration2 blurred regions to adjust blur effect appropriately when
needed

Requires: https://invent.kde.org/plasma/kdecoration/-/merge_requests/17

M  +3    -0    autotests/test_window_paint_data.cpp
M  +15   -0    src/effects.cpp
M  +1    -0    src/effects.h
M  +1    -0    src/effects/CMakeLists.txt
M  +34   -2    src/effects/blur/blur.cpp
M  +2    -0    src/effects/blur/blur.h
M  +17   -0    src/libkwineffects/kwineffects.h

https://invent.kde.org/plasma/kwin/commit/bc145b614c9f1c7594b01d88a2dfbebead50d489

Thanks for working on this. In which Plasma version will this be released? Is it set or not decided yet?

(In reply to Michał Dybczak from comment #76)
> Thanks for working on this. In which Plasma version will this be released?
> Is it set or not decided yet?

noone knows, first it must be validated, confirm the fix etc. etc... 
it will be ready when it is ready...

Git commit bcff044c738891aa7e55b67cf6b21f94319eead4 by Michail Vourlakos.
Committed on 06/03/2022 at 09:58.
Pushed by mvourlakos into branch 'master'.

[aurorae] - support blurregion from kdecoration2

This is an approach for aurorae engine to publish masks for its decorated windows in order to avoid out of window blurring at the decoration corners. Aurorae themes are now able to specify a **mask** element inside **decoration.svg** file like plasma themes already do. Mask is used afterwards to calculate theme's blur region.


| Before | After |
| ------ | ----- |
|![before](/uploads/26014e79c3d5d45ba12fa5cf62294b1c/before.png)|![after](/uploads/923d7021eaaf322be96b611c73558666/after.png)|

Adjusted Aurorae theme for testing: [ROUNDED-DARK.tar.gz](/uploads/082f60ad4311e3e296b7faeeb7c97dac/ROUNDED-DARK.tar.gz)

M  +31   -0    src/plugins/kdecorations/aurorae/src/aurorae.cpp
M  +1    -0    src/plugins/kdecorations/aurorae/src/aurorae.h
M  +11   -0    src/plugins/kdecorations/aurorae/src/qml/aurorae.qml
M  +6    -3    src/plugins/kdecorations/aurorae/theme-description

https://invent.kde.org/plasma/kwin/commit/bcff044c738891aa7e55b67cf6b21f94319eead4

Created attachment 149738 [details]
Korners bug on plasma 5.25

Today I upgraded to Plasma 5.25 but it seems I'm still getting the corners bug. I'm using the Rounded-dark theme which is provided specifically to test this, and I often still get artifacts/flickering in the corners (see screenshot). Usually activating/deactivating the window or moving it fixes the problem (temporarily)

To add to my previous comment, I dug deeper and found out the following:

- The korners bug still happens only in one case for me: if I enable blurring in the konsole settings, it triggers the bug *only for the konsole window*
- Firefox has a separate issue where the corners get glitches, but that's independent of the blur effect so I'll open another bug for that

(In reply to Alberto Mattea from comment #80)
> To add to my previous comment, I dug deeper and found out the following:
> 
> - The korners bug still happens only in one case for me: if I enable
> blurring in the konsole settings, it triggers the bug *only for the konsole
> window*
> - Firefox has a separate issue where the corners get glitches, but that's
> independent of the blur effect so I'll open another bug for that

You probably need to open a new bug for konsole. Konsole probably needs to update its implementation.

I use my own theme to test this (git master branch of https://github.com/paulmcauley/classik which has the API implemented).

The main problem I found is that on Wayland, blurred corners are quite aliased ( https://bugs.kde.org/show_bug.cgi?id=453229  ).

(In reply to Michail Vourlakos from comment #81)
> (In reply to Alberto Mattea from comment #80)
> > To add to my previous comment, I dug deeper and found out the following:
> > 
> > - The korners bug still happens only in one case for me: if I enable
> > blurring in the konsole settings, it triggers the bug *only for the konsole
> > window*
> > - Firefox has a separate issue where the corners get glitches, but that's
> > independent of the blur effect so I'll open another bug for that
> 
> You probably need to open a new bug for konsole. Konsole probably needs to
> update its implementation.

https://bugs.kde.org/show_bug.cgi?id=455491

Correct me if I'm wrong, but I understand, that in order the fix would work, the aurorae theme must be updated to follow the fix specification? In other words, the fix is not fixing the issue on the various aurorae third party themes, it only allows for proper corner displays if the aurorae theme will be properly updated?

I use WhiteSur aurorae theme, it was updated and so far, I can see the corner issue is not visible, but I expect to be visible with many other themes, that are either not actively developed or if developers are not quick with the update (or not aware that they must do something or what to do).

I checked Konsole and no corner bug, which suggests that this is not a Konsole problem but the aurorae theme problem.

(In reply to Michał Dybczak from comment #84)

WhiteSur's Aurorae theme on the store has not been updated since 2020 as far as I can tell: https://store.kde.org/p/1398835/

Themes have to be manually updated to have blur now. All existing themes will just be translucent. Since much of WhiteSur is opaque, you are likely just seeing the absence of blur. The bottom half of the decoration is probably translucent (well, more than usual). Check "Huge Borders" to see if it is being blurred.

The Konsole problem we are seeing seems to be due to people enabling blur in Konsole. Settings > Edit Current Profile > Appearance > Edit > Blur Background. This appears to draw a blurred rectangle behind Konsole, thus recreating Korners. Aurorae is fine for the most part.

Weird. After the 5.25 update. Discover saw and installed the update... I see the last commit 21 days ago,

I do have blurry background in Konsole and can't see the bug.
I tested various third party aurorae themes and corner bug wasn't visible.

However, it appears temporarily on Firefox when its window becomes unfocused. After being focused, the bug disappears when the window is moved.

What settings do you have? I mean, what aurorae theme? I may try it as well. 

Ah wait... This is really strange. I just saw corner bug on Konsole too, then I minimized all windows, un-minimized them and now no corner bug on any of the Konsole windows... Note, that I check on light, plain background, where usually this bug was visible the most.

Anyway, since this sometimes appears on Konsole and Firefox, other apps may be afflicted too. Hmm... This is too weird. However, the bug is not so striking as it was before and oftentimes it's not visible.

Then maybe let's establish some base themes where we test if the bug is still there or not. Which aurorae theme was update and should not have corner bug and still seem to have it?

(In reply to Michał Dybczak from comment #86)
> Weird. After the 5.25 update. Discover saw and installed the update... I see
> the last commit 21 days ago,

The commit doesn't necessarily mean that the file on the store (i.e. Discover) was updated, nor does it mean that the Aurorae theme was updated.

> I do have blurry background in Konsole and can't see the bug.
> I tested various third party aurorae themes and corner bug wasn't visible.

How many themes were blurred on KDE 5.25?

> Ah wait... This is really strange. I just saw corner bug on Konsole too,
> then I minimized all windows, un-minimized them and now no corner bug on any
> of the Konsole windows... Note, that I check on light, plain background,
> where usually this bug was visible the most.

A plain background isn't always the best way to check. The best way to check is between 2 very different colors/values. e.g. the built-in "Grey" wallpaper. Move the window corner around in that spot and you should be able to see it.

> Anyway, since this sometimes appears on Konsole and Firefox, other apps may
> be afflicted too. Hmm... This is too weird. However, the bug is not so
> striking as it was before and oftentimes it's not visible.

Do you use shaders (e.g. Lightly Shaders) or perhaps force blur?

> Then maybe let's establish some base themes where we test if the bug is
> still there or not. Which aurorae theme was update and should not have
> corner bug and still seem to have it?

I don't think many theme developers heard the news. Willow should be updated: https://www.pling.com/p/1561335/ I do not see corners on it for other windows, but I do see corners on Konsole when I enable blurring in it.

To show the bug, select "Willow Dark Blur" as your window decoration. Set your wallpaper to "Grey". Set your color scheme to something like, light Breeze Light. In the top right area of the wallpaper, there are many dark slivers surrounded by white. Move your top-right window corner onto one of the dark slivers. You should not see it for other windows. Konsole, with Blur Background enabled should show a white corner. Increasing blur to the maximum strength will also help show the bug.

To fix this bug window borders must be clearly defined by any window decoration that adds transparent pixels that shouldn't be blurred AND the blur effect has to implement the window borders, so it won't blur pixels outside of the borders.

@SirLennox yes that's how this bug got fixed. Some code changed on our side, and now themes need to be updated to make use of it.

(In reply to Nate Graham from comment #89)
> @SirLennox yes that's how this bug got fixed. Some code changed on our side,
> and now themes need to be updated to make use of it.

Is there like a documentation or something about this?

I don't know, sorry. Probably not, unfortunately.

https://psifidotos.blogspot.com/2022/03/kornersfix.html?m=1