Created attachment 147017 [details] Panel with the broken rendering SUMMARY After https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1474 landed, panels (and some Plasma dialogs) are drawn with a black tint on X11. Reverting 745e2c08 in plasmashell restores the previous behavior (no other changes needed). KWin supporting information and screenshots are attached. STEPS TO REPRODUCE 1. Start plasmashell with 745e2c08 applied. OBSERVED RESULT Panel is drawn with a black tint and has visible artifacts (see screenshots). Some Plasma dialogs too (see screenshots). EXPECTED RESULT Panel should be transparent. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed / latest master (available in About System) KDE Plasma Version: latest master KDE Frameworks Version: latest master Qt Version: latest 5.15 + the full KDE patch set ADDITIONAL INFORMATION This problem does not seem to occur on Wayland.
Created attachment 147018 [details] Panel with correct rendering
Created attachment 147019 [details] Detail of the artifacts on the panel
Created attachment 147020 [details] Broken rendering with dialog (panel options)
Created attachment 147021 [details] KWin supporting information
Also the translucent background seems broken.
https://invent.kde.org/plasma/plasma-workspace/-/blob/5824e6362008988f74d07c9fce930e93294b990d/shell/desktopview.cpp#L37 if you change Qt::black to Qt::red, are panel corners red? Do new panels have opaque background?
(In reply to Vlad Zahorodnii from comment #6) > https://invent.kde.org/plasma/plasma-workspace/-/blob/ > 5824e6362008988f74d07c9fce930e93294b990d/shell/desktopview.cpp#L37 if you > change Qt::black to Qt::red, are panel corners red? Do new panels have > opaque background? I'll test the color when I'm home, but I can already tell you that new panels are properly transparent, but their dialogs are still black tinted.
(In reply to Luca Beltrame from comment #7) > I'll test the color when I'm home, but I can already tell you that new > panels are properly transparent, but their dialogs are still black tinted. Well, this is weird. The panel stays black-ish when I change the setColor call. (I set it to Qt::red). I have no idea why that single call changes everything still.
I also need to rectify what I wrote earlier. It seemed to me that new panels were correct: but I just tested it again and no, new panels appear dark as well. I made sure by clearing all caches before adding one.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1485
Git commit 4cd6ec7446b65213448530a64d584b54268a5ef4 by Fushan Wen, on behalf of Vlad Zahorodnii. Committed on 23/02/2022 at 09:24. Pushed by fusionfuture into branch 'master'. Make DesktopView set black clear color only on Wayland 745e2c08289b35ccd007cf436f653a6e92b45ef9 made DesktopView set clear color to "black" so the compositor could avoid overdraw and thus optimizing rendering. In the perfect world, such a change would create no regressions, but for some reason, it made panels lose alpha channel on X11. That makes absolutely no any sense. DesktopView and PanelView are two totally different code paths. So changes in DesktopView should not affect the PanelView. This looks like a QtXCB bug. Ideally, we should add workarounds only after finding what creates a problem, but this one is particularly hard because many people who have tried to reproduce that issue weren't successful. Somebody who can reproduce the issue would have to be able to build Qt from source code and add qDebug()s. These requirements are too steep, thus adding a platform check seems like the best option at the moment. M +6 -1 shell/desktopview.cpp https://invent.kde.org/plasma/plasma-workspace/commit/4cd6ec7446b65213448530a64d584b54268a5ef4