sway version 1.0-rc1-123-gd016848b
Specific tray apps seem to make swaybar repeatedly poll for image/asset files.
kdeconnect-indicator doesn't do it, but kmix, radiotray-ng (gtk) and soulseekqt do. the icon for kmix is a red face, but the radiotray-ng and soulseekqt icons appear as they should.
swaybar CPU usage without any tray apps is about 0.5%. For each troublesome app open, it goes up roughly by 3.5/5%.
mxmilkiib
All 5 comments
I can confirm that telegram-desktop 1.5.11 and mumble 1.2.19 also cause this on sway 1.0-rc3.
By the way, the colours of telegram-desktop's tray icon are messed up as well (#3635).
approximately 15 seconds of stracing swaybar with tdesktop's icon in the tray
porrided
on 28 Feb 2019
This issue is now being tracked in https://github.com/swaywm/sway/issues/3799.
The kmix issue is, I think, a case of missing icons. It's looking for an icon called 'audio-volume-high' or something, does that exists on your filesystem?
ianyfan
on 28 Feb 2019
Hmm. Whilst tray support isn't final, it appears the individual apps could be more conservative. Not sure how much swaybar can do when apps do this, are the apps expecting some specific tray feature, or are they just generally misbehaving?
mxmilkiib
on 1 Mar 2019
Maybe an icon name cache could be implemented. Or maybe it's just an app bug.
emersion
on 1 Mar 2019
Maybe an icon name cache could be implemented.
This is the solution. Here is a full outline of the problem:
Icon themes define, for each size of icon, its range of acceptable rendering sizes, e.g. it may say that icons of size 22x22 can be resized to between 20 & 24 to be rendered. Hence, when swaybar searches for an icon to render, it tries to find an icon for which the current rendering height falls within the icon's acceptable range for rendering, but if that is not possible, it then finds the icons whose acceptable range is closest to the rendering size.
In each case, it also stores the acceptable range, with the idea that if the height of swaybar changes so that it falls out of that range, it can look for a new icon again. However, this has the side-effect that if the icon was not in the acceptable range to begin with, it will look for a new icon if the height does not change, which is usually the status quo, causing swaybar to poll every single possible icon file twice on every render.
As outlined in the specification the main solution would be to only traverse the file tree once, reading it all into memory, but this would require more implementation work, when initially I was just pushing to get the feature out there in a way that works. However, there could also be more state defined to monitor if the height changes, since if it does not, the icon should not change either.
Sorry for this problem, but I hope you understand why it's happening. When I get time, I hope to revisit this problem, since it's not too conceptually hard, just fiddly to work out the details, but in the meantime, contributions are welcome :)
ianyfan
on 1 Mar 2019
Related issues
WhyNotHugo
路
3Comments
ddevault
路
4Comments
RyanDwyer
路
3Comments
soymjolk
路
3Comments
mcmfb
路
3Comments
Most helpful comment
This is the solution. Here is a full outline of the problem:
Icon themes define, for each size of icon, its range of acceptable rendering sizes, e.g. it may say that icons of size 22x22 can be resized to between 20 & 24 to be rendered. Hence, when swaybar searches for an icon to render, it tries to find an icon for which the current rendering height falls within the icon's acceptable range for rendering, but if that is not possible, it then finds the icons whose acceptable range is closest to the rendering size.
In each case, it also stores the acceptable range, with the idea that if the height of swaybar changes so that it falls out of that range, it can look for a new icon again. However, this has the side-effect that if the icon was not in the acceptable range to begin with, it will look for a new icon if the height does not change, which is usually the status quo, causing swaybar to poll every single possible icon file twice on every render.
As outlined in the specification the main solution would be to only traverse the file tree once, reading it all into memory, but this would require more implementation work, when initially I was just pushing to get the feature out there in a way that works. However, there could also be more state defined to monitor if the height changes, since if it does not, the icon should not change either.
Sorry for this problem, but I hope you understand why it's happening. When I get time, I hope to revisit this problem, since it's not too conceptually hard, just fiddly to work out the details, but in the meantime, contributions are welcome :)