Summary: | Flickering in systray for apps that change tooltip or on mouse hover | ||
---|---|---|---|
Product: | [Frameworks and Libraries] libplasma | Reporter: | Christian (Fuchs) <kde> |
Component: | libplasma | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | CONFIRMED --- | ||
Severity: | minor | CC: | ahiemstra, frankebay99, me, nate, notmart, olib141 |
Priority: | NOR | Keywords: | regression |
Version: | 5.103.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=463061 | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | screencast of the issue, first half is app only with no user interaction, second half is mouse hover |
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. |