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.
Is anyone still able to reproduce this in Plasma 6, where we switched to using Kirigami.Icon?
*** Bug 463061 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #6) > Is anyone still able to reproduce this in Plasma 6, where we switched to > using Kirigami.Icon? I can't reproduce it on my end.
Created attachment 173287 [details] Flickering visible Yep, still reproducible for me in Plasma 6.1.4, arguably less than before, but definitely still there
(In reply to Christian (Fuchs) from comment #9) > Created attachment 173287 [details] > Flickering visible > > Yep, still reproducible for me in Plasma 6.1.4, arguably less than before, > but definitely still there Is this Ktorrent? I can't reproduce the problem with qBittorrent.
(In reply to mozo from comment #10) > (In reply to Christian (Fuchs) from comment #9) > > Created attachment 173287 [details] > > Flickering visible > > > > Yep, still reproducible for me in Plasma 6.1.4, arguably less than before, > > but definitely still there > > Is this Ktorrent? I can't reproduce the problem with qBittorrent. Yeah, that's ktorrent, 24.08.0
I don't know why but I can't reproduce it, see the attachment. With Ktorrent, normal qBittorrent and flatpak qBittorrent, all uploading or downloading.
Created attachment 173289 [details] Systray recording
Aha, I found the way to reproduce this: Use a dark color scheme. With Breeze Dark, I can reproduce it when hovering over almost all icons for active applets in the system tray.
*** Bug 492470 has been marked as a duplicate of this bug. ***
can reproduce. is not an issue of the systray in particular, but if the same applet gets positioned in the panel or desktop the issue happens as well, so is an issue of that icon control representation itself
this is because Kirigami.Icon animations work in the following way: * fade in the new icon over the old icon (in this case the one with mouse over effect over the one without) * then, fade out the old icon beneath this will make it look as the icon is bigger/brighter when both icons are visible because the semitransparent antialiased borders will overlap each other and become less transparent. a proper fix i think it would be instead of having 2 graphics scene nodes overlapping each other, having a single node with a fragment shader that does actual cross fade between the pixels
Oh, only just now saw this bug report. Here are reports with recordings from me for a few distinct issues interplaying here: Bug 489759, Bug 489756, Bug 489761 Not sure if any should be marked as duplicate or merged?
Thanks, I'll take a look.
*** Bug 489756 has been marked as a duplicate of this bug. ***
*** Bug 489759 has been marked as a duplicate of this bug. ***
Both ultimately have the same root cause as this issue. Thanks a lot!
The code in question is here, in case anyone wants to play around with it https://invent.kde.org/frameworks/kirigami/-/blob/03efe7da6ee92a4fbf47f4c602ffdc2200298d49/src/primitives/icon.cpp#L223 Unfortunately I can only wistfully stare at this code since I can't set up a build environment currently, but I'd love to help fix these bugs.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1645
Git commit 9926955b7061b911fce67fcdb1bcbd3aae690932 by Marco Martin. Committed on 25/10/2024 at 13:38. Pushed by mart into branch 'master'. Icon: Always respect the animated property It used to animate from inactive to active regardless and from enabled to disabled. Always respect the animated property. if is disabled, never do the animation. M +1 -6 src/primitives/icon.cpp M +0 -1 src/primitives/icon.h https://invent.kde.org/frameworks/kirigami/-/commit/9926955b7061b911fce67fcdb1bcbd3aae690932