Created attachment 156678 [details] screencast of the issue, first half is app only with no user interaction, second half is mouse hover SUMMARY The flickering in https://bugs.kde.org/show_bug.cgi?id=463685 / https://bugs.kde.org/show_bug.cgi?id=463061 is still present, new bug report because it's not specific to qbittorrrent (even though that's a good candidate to trigger it) and the others are closed. STEPS TO REPRODUCE 1. Have an icon in the systray that changes its tooltip 2. Alternatively mouse-hover an icon such as volume OBSERVED RESULT Heavy flickering, which (especially when not caused by mouse hover but rather by the app itself) causes the eyes to focus there as there is movement EXPECTED RESULT No flickering SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-200.fc37.x86_64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 7700X 8-Core Processor Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4080/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7D70 System Version: 1.0 Sidenote: also reproducible on my notebook which has an Intel CPU and GPU, same software versions ADDITIONAL INFORMATION Introduced by https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/649 Not fixed yet by https://invent.kde.org/frameworks/plasma-framework/commit/3fcd43a6ed03d0aff188dfc190cc464c34302a1f The question if this is caused by an animation to fade-in / -out is if that animation is really needed as is. Because if it is mainly / just for aesthetics, this most certainly does the opposite of what it tries to achieve. Also: is it needed for the icon to reload / do that whenever the tooltip changes? If not, disabling that would at least fix it for the case where there is no user interaction, which would be a good start
Cannot reproduce myself with current git master.
I have seen this issue with qBittorrent before, but I am presently on 5.27.1 and can't see it. I think it's probably still around, but appears inconsistently. https://github.com/qbittorrent/qBittorrent/issues/18217 I'm believe this is a Plasma issue, not a qBittorrent one, but I don't recall seeing it with other tooltips (though none are as dynamic).
The animation used to rely on a bunch of custom scene graph code to fade between two icons. This was changed to do the crossfade using plain nodes, which lead to the initial bug because of differences in blending. The animation was changed so that rather than crossfading, we first fade in the new icon and then fade out the old icon. The only artifact that this produces is when there are semi-transparent pixels that cover the same area, these can end up being drawn twice. For most icons this isn't a big problem, except some like the volume icons that (in my opinion, incorrectly) use transparency for the "muted" lines. With regards to the issues mentioned here specifically, for the qBittorrent case we should improve how we detect icon changes rather than trying to work around it in other places, as the core of the issue there is the icon being detected as changed but not actually changing. For the other icon, when you hover over an item in the systray, there is a highlight effect applied that is done by changing the icon pixels, so the icon changes and the animation is triggered. As the icon uses semi-transparency for muting the colour, it ends up being drawn twice and you end up with an effect where the "muted" lines are slightly less muted for a short moment.
(In reply to Arjen Hiemstra from comment #3) > With regards to the issues mentioned here specifically, for the qBittorrent > case we should improve how we detect icon changes rather than trying to work > around it in other places, as the core of the issue there is the icon being > detected as changed but not actually changing. Yes. The case of "flickering without user interaction" being solved would already do a lot, since at least when you mouse-hover or do something, chances are your eyes are already focussed on the systray area, so you won't be distracted by a flickering in the corner of your field of view. That would help a lot. Still: > For the other icon, when you > hover over an item in the systray, there is a highlight effect applied that > is done by changing the icon pixels, so the icon changes and the animation > is triggered. As the icon uses semi-transparency for muting the colour, it > ends up being drawn twice and you end up with an effect where the "muted" > lines are slightly less muted for a short moment. while I use a custom (older, but official) volume icon and the newer one might not suffer as much from it, the current (wireless) network icon does. As do probably do a handful others, so preferably this would also be fixed not in the icons or how they use transparency, but rather the effect.
Thank you for fixing this! I have this issue with qbittorrent and MEGASync icons, both are black and white. My qbittorrent icon is a different one than the one on the original screenshot but it's the same flickering behavior. Happy to see it part of the list.