Manually setting corner radius of menu's blurred area in kvconfig?

[doncsugar]

It appears that we have reached critical mass and are willing to try anything to resolve "Korners" over in KDE. As seen here, an early suggestion would be to allow manually setting the radius of the blurred area behind Aurorae decorations. Whilst hacky and will fail to support more extravagant styles, I believe the benefits to the many (and more commonly used) simple rounded styles will benefit from a clean appearance—as will users.

For themes that have very high values for the radius, this unsettling contrast between blur and menu is even more noticeable. Is it possible for such functionality to be implemented into Kvantum?

[tsujan]

Is it possible for such functionality to be implemented into Kvantum?

Kvantum doesn't depend on kdecoration. So, those methods aren't related to it.

The only rounded corners in top level windows that are controlled by Kvantum are in menus. The rest is controlled by KWin (if present). Unlike buttons and some other elements, a menu SVG element shouldn't have very rounded corners in Kvantum.

It may be possible to add a key like menu_blur_roundness and choose its value by trial and error for a theme that has rounded menus. But it might need lots of code lines for such a small effect (and only under KWin) and I'm not sure it'll be CPU-friendly. If I find the time, I might do some experiments.

[tsujan]

In Kvantum, the whole SVG element of a translucent menu can have quite rounded corners (as it does in most themes included in Kvantum) but most of that roundness belongs to the menu shadow, which is excluded from blurring. Moreover, "corner blurring" depends on the contrast that may exist in the background itself and isn't always visible. Usually just a few pixels at the corners may need to be excluded. This screenshot shows the "worst" thing that may happen (at the top corners):

However, the exact number of pixels can't be calculated because it depends on the SVG elements.

[doncsugar]

However, the exact number of pixels can't be calculated because it depends on the SVG elements.

What methods are there to determine the number of pixels? Is the inverse of "full" pixels for a given radius enough?

Are there other manual ways of handling it than supplying a radius for Kvantum to implement?

[tsujan]

The number of pixels should be derived from the radius. That's math and isn't a problem (although it may take time to find the best code). The probable problem is about the extra CPU usage caused by changing a single blurred rectangle to a region consisting of several rectangles — in your screenshot, 21.

[doncsugar]

Which screenshot has 21? 21 rectangles? 21 pixels to be omitted?

Also, I'm not keen on how the code works, but could you say which of these three pictures illustrates what you mean by "several rectangles"?

I cannot figure out where the 21 comes from.

[tsujan]

None. I was referring to the whole "rounded" rectangle, not just its top left corner.

Anyway, it's implemented now.

[tsujan]

OK, I tested and it worked fine. This is without "blur rounding" and with a scale factor of 2:

And this with a "blur radius" of 2:

I saw no tangible difference in CPU usage, but I have a powerful laptop. However, it'll be optional.

EDIT: The blur radius is only 2 but because the scale factor is 2, it seems to be 4.

[doncsugar]

The entire region seems to be shifted down 1 pixel in both of these images.

I will do a rudimentary benchmark on my notoriously slow machine for a few radii and let you know if I see any performance issues related to high radii there. For reference, what are your specifications?

I will also check for radius values that will best hide the sharp corners:

One last concern regarding an issue I spoke with you about: Now that a radius for the blur is specified, does that mean when a user reduces the opacity of the menu, the discrepancy between the shadow and the shadow inside the menu's rectangle will be more obvious?

[tsujan]

The entire region seems to be shifted down 1 pixel in both of these images.

No. It's related to anti-aliasing.

[tsujan]

Now that a radius for the blur is specified, does that mean when a user reduces the opacity of the menu, the discrepancy between the shadow and the shadow inside the menu's rectangle will be more obvious?

If you mean 4 tiny parts of the shadow outside rounded corners, no. For now, I think it isn't worth adding code lines.

[tsujan]

Done in d87dcf2

Usually, a value of 2 is enough for menus/tooltips that have rounded corners.

Thanks for the discussion!

[doncsugar]

I have tested it. I like that you incorporated the radius into the Manager.

Why do you suppose the other corners are being squashed? The screenshot is at radius 10:

Tooltip may exhibit odd behavior if the radius is larger than half its height.

[tsujan]

Tooltip may exhibit odd behavior if the radius is larger than half its height.

The code doesn't allow a radius > 10.

EDIT: → 8e79ca8