Created attachment 148474 [details]
Screenshot of ClassiK window decoration with 20% opacity titlebars/borders and blur on, corner radius=4, shadows disabled to emphasise bug. The corners exhibit very blocky aliasing.
Hello, I have made a first attempt at implementing the new setBlurRegion() API (due to land in Plasma 5.25) in my C++ Window Decoration. This can be found on the branch at: https://github.com/paulmcauley/classik/tree/kornerbug-fix-plasma5.25
I construct my window shape using a QPainterPath (called m_windowPath) and then call setBlurRegion as follows:
setBlurRegion( QRegion( m_windowPath->toFillPolygon().toPolygon() ) ) ;
The results on X11 are excellent and produces very smooth corners when transparency and blur are enabled. However, on Wayland, the corners of the blur region are very blocky/aliased in appearance.
Operating System: openSUSE Tumbleweed 20220421
KDE Plasma Version: 5.24.80
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.2
Kernel Version: 5.17.3-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz
Memory: 31.2 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 630
Manufacturer: Dell Inc.
Product Name: XPS 15 9560
Created attachment 148475 [details]
X11 by contrast. Screenshot of ClassiK window decoration with 20% opacity titlebars/borders and blur on, corner radius=4, shadows disabled to emphasise bug. The corners are very smooth.
By contrast here is a similar screenshot on X11. It results in very smooth corners to the blur region.
I should also mention that the above 2 screenshots are at 250% scaling.
I was looking into this more, and guessing this is probably because in Wayland scaled rendering is done relative to a smaller 100% scaled grid (e.g. at 250% scaling with a 2840x2160 display, rendering is done relative to 1536x864), so on Wayland you probably need to use floating point values for more precise shapes on screens with scaling > 100%.
You can, however, only construct a QRegion using integers (QRect and QPolygon; not QRectF and QPolygonF).
In my own window decoration ( https://github.com/paulmcauley/classik/commit/fe48c052f529e889706214c9af3db200fbfdb2a8#diff-1c44374ff8b2c6b8bea9596fe31ea4878a23bea2f62d2ce01dcbdf119dc98474R1319 ) I convert from a QPainterPath (in the shape of the window) to a QPolygonF to a QPolygon and finally to a QRegion.
If my assumption about the cause of this problem is correct, I would then propose extending the setBlurRegion() API in the decoration to accept a QPainterPath or a QPolygonF. A QPolygonF can then be easily converted to a QPolygon (just converts qreal to int) and then to a QRegion at the last minute after scaling and directly before the effect is applied to the actual pixels on screen.
Created attachment 149902 [details]
The problem still exists in the floating panel.
(In reply to Mohammad from comment #3)
> Created attachment 149902 [details]
> floating panel
> The problem still exists in the floating panel.
The setBlurRegion() function is only for window decorations, so this bug wouldn't cover that.
That said, the KWindowEffects::enableBlurBehind function used for blurring regions in applications only accepts QRegions as well, so I suspect if they were ever used properly, that under Wayland you would not have smooth corners on HiDPI Wayland with KWindowEffects::enableBlurBehind either.