| Summary: | With dark color scheme, icons in active area of System Tray flicker on mouse hover | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | Christian (Fuchs) <kde> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | ahiemstra, frankebay99, kdebugrtackingsystem.oyrus, nate, notmart, olib141, smitha, variable_valuables761 |
| Priority: | NOR | Keywords: | regression |
| Version First Reported In: | 5.103.0 | ||
| Target Milestone: | Not decided | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kirigami/-/commit/9926955b7061b911fce67fcdb1bcbd3aae690932 | Version Fixed In: | 6.8 |
| Sentry Crash Report: | |||
| Attachments: |
screencast of the issue, first half is app only with no user interaction, second half is mouse hover
Flickering visible Systray recording |
||
|
Description
Christian (Fuchs)
2023-02-24 15:27:43 UTC
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 |