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] floating panel 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.