Bug 451778

Summary:	Blur/Kornerbug enabled even when a window is set to opaque
Product:	[Plasma] kwin	Reporter:	Paul McAuley <kde>
Component:	effects-various	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	kde, nate, openmindead, postix, yule2000
Priority:	NOR
Version First Reported In:	5.24.3
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	New Kornerbug artefact visible in top corners of window. In this case transparency is disabled and the window is set to opaque with setOpaque(true). This artefact did not occur in 5.23 5.24.1 X11 - bug is not present 5.24.1 Wayland - bug is not present 5.24.3 - bug is present on both Wayland and X11 kwin 5e448f063 ("effects/contrast: Remove paint area tracking", 2022-02-16) does NOT have the bug 0kwin 0a8de6c0 ("effects/blur: Avoid shrinking unrelated opaque regions", 2022-02-19) DOES have the bug

Description Paul McAuley 2022-03-21 21:08:03 UTC

Created attachment 147655 [details]
New Kornerbug artefact visible in top corners of window. In this case transparency is disabled and the window is set to opaque with setOpaque(true). This artefact did not occur in 5.23

Hello,

I have noticed some regressions (or intentional changes??) with recent point releases of Plasma 5.24 (I did not notice such changes 5.23 or in the original Plasma 5.24 release).

I am the author of the Classik C++ window decoration plugin ( https://github.com/paulmcauley/classik ). I have blur enabled in my .json file as I have translucency as an option. 

In 5.23, and early 5.24 builds I used the same technique as the Lightly window decoration ( https://github.com/Luwx/Lightly ) to control when blur should be on or off. Namely, I use Decoration::setOpaque(true) to dynamically turn blur off and Decoration::setOpaque(false) to dynamically turn blur on. When translucency and blur was not needed I therefore used Decoration::setOpaque(true), and this prevented the Kornerbug from appearing by disabling blur for most default cases when blur was not needed.

My problem is that this no longer works. I now get the kornerbug when using 5.24.3 and Decoration::setOpaque(true), suggesting that blur has been enabled even on a window set to opaque.

I understand that there is to be a new API for setting a blurRegion mask in 5.25 to avoid kornerbug issues, but I am seeing changes here in 5.24.3. If this is an intentional change, what is the correct way to programmatically inform blur to disable? Is setOpaque() still used?

Thanks,

Paul
 
Operating System: openSUSE Leap 15.3
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.2
Kernel Version: 5.3.18-150300.59.54-preempt (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

Comment 1 David Edmundson 2022-03-21 22:05:19 UTC

Nothing should have changed in the 5.24.x series.

Comment 2 Paul McAuley 2022-03-22 13:20:52 UTC

(In reply to David Edmundson from comment #1)
> Nothing should have changed in the 5.24.x series.

You are right - I double checked with a 5.24.0 ISO and it does also have this problem. 5.23 releases definitely did not. Maybe I was confused by the 5.24 beta releases.


The reason the Breeze window decoration does not have this problem is because it has blur disabled in its .json file and also has setOpaque(false) set for non-maximized windows.

Comment 3 Paul McAuley 2022-03-25 12:15:42 UTC

Created attachment 147721 [details]
5.24.1 X11 - bug is not present

Comment 4 Paul McAuley 2022-03-25 12:16:25 UTC

Created attachment 147722 [details]
5.24.1 Wayland - bug is not present

Comment 5 Paul McAuley 2022-03-25 12:17:54 UTC

Created attachment 147723 [details]
5.24.3 - bug is present on both Wayland and X11

Comment 6 Paul McAuley 2022-03-25 12:20:26 UTC

(In reply to Paul McAuley from comment #2)
> (In reply to David Edmundson from comment #1)
> > Nothing should have changed in the 5.24.x series.
> 
> You are right - I double checked with a 5.24.0 ISO and it does also have
> this problem. 5.23 releases definitely did not. Maybe I was confused by the
> 5.24 beta releases.
> 
> 
> The reason the Breeze window decoration does not have this problem is
> because it has blur disabled in its .json file and also has setOpaque(false)
> set for non-maximized windows.

UPDATE: I also found a machine that was still on Plasma 5.24.1 and it does not have this bug. Immediately upon updating to Plasma 5.24.3 the bug appears. There seems to be a definite difference between 5.24.1 and later releases (see added screenshots).

Comment 7 Paul McAuley 2022-03-30 19:16:46 UTC

Created attachment 147848 [details]
kwin 5e448f063 ("effects/contrast: Remove paint area tracking", 2022-02-16) does NOT have the bug

Comment 8 Paul McAuley 2022-03-30 19:22:58 UTC

Created attachment 147849 [details]
0kwin 0a8de6c0 ("effects/blur: Avoid shrinking unrelated opaque regions", 2022-02-19) DOES have the bug

I managed to pinpoint this bug exactly to be caused by kwin commit 0a8de6c0 ("effects/blur: Avoid shrinking unrelated opaque regions", 2022-02-19) (see screenshot)

This would correspond to the merge request at https://invent.kde.org/plasma/kwin/-/merge_requests/2045

Comment 9 Paul McAuley 2022-04-25 19:22:25 UTC

I have reworked my C++ window decoration to use the new setBlurRegion API (due 5.25) on the branch at https://github.com/paulmcauley/classik/tree/kornerbug-fix-plasma5.25 This has worked around this issue for my specific case for now. I had to remove the blur config line entirely from the .json file and also match the Breeze behaviour of setting setOpaque(false) for non-maximized windows (even when I know that no transparency will be used in the window decoration) to avoid any artefacts.

However, it would be good to get some guidance on what setOpaque() is for. Should a non-maximized window ever have setOpaque(true) set if transparency is never going to be used in the window decoration? I would have assumed this would be the case, and therefore that this bug is still generally relevant.