emersion
Consider caching notification icons
First off, love the way an icon theme can be configured so easily in mako vs. dunst, for example, where a plethora of paths must be specified for every possible combination of icons one wishes to be made available so the daemon can display them.
Allowing the user to specify the icon by name and searching for it in the configured icon theme setting, vaguely as per the freedesktop spec algorithm, is fantastic. Alas, there's a clear downside to this when it comes to relatively heavily recurrent notifications: the search algorithm must be performed every single time.
Picture the following use case. Upon changing an audio device's audio level, be it an increase, decrease, or even (un)muting it entirely, it would be nice to prompt the user with a notification of the current status alongside a symbolic icon of sorts. If used scarcely, this doesn't necessarily pose an issue, as the notification only shows up every now and again. Say the user has this behavior bound to a keyboard or mouse key, and wishes to perform a couple of increases or decreases at once by holding said binding. One would expect that, per invocation, a notification with the current status would appear. Unfortunately, since it might take some time to find the desired icon to be shown, leading to what I would consider a degraded experience. A working one, but maybe not the most appealing.
Of course, on one hand, the solution could be as simple as hard-coding the path to the given icon absolutely, which would certainly boost performance, skipping icon search entirely. However, this is, obviously, not a flexible solution. If users install a new icon theme, they will have to scour every place they hard-coded the icon path in and change it manually.
On the other hand, one potential solution could be the existence of a lazy runtime cache, i.e., the search is performed only once, and its result stored away for subsequent queries. This could come in the form of a directory in the typical $XDG_RUNTIME_DIR or /tmp, as a suitable fallback, and, within it, possibly links to the image file in question.
Now, I know from experience caches usually tend to pose a few concerns, namely when should they be invalidated. As per the spec, once an icon is found, the search should halt immediately, returning the most adequate result. This coupled with the fact that the icons in the theme will most likely not change unless users wish to interchange the icon theme themselves. This is great, because this is when the cache should be invalidated, i.e., when mako requires a reload (or is initialized, for that matter, but that's trivial).
It isn't quite clear in my head how this could be implemented, but for some days now, I've been giving this some thinking and decided I would share. Not necessarily as an issue, but more like the title entails, a consideration. An open proposal, if you will. Would love feedback on why this could be a great or horrible idea.
This could come in the form of a directory in the typical $XDG_RUNTIME_DIR or /tmp, as a suitable fallback, and, within it, possibly links to the image file in question.
I think an in-memory ring buffer of file paths would be simpler.
I agree we should have some cache, iirc it was discussed on the original PR but left out to keep it as simple as possible.
A small in memory LRU would also be pretty easy to pull off with a wl_list, I'm ok with either approach. We can probably skip making anything about it (max size, etc) configurable until someone asks for it.
We probably only want to do this for icons fetched by path, since image data may be arbitrarily large and is unlikely to be reused.
I've been working on dunst's icon code. At first I tried just copying mako's implementation (https://github.com/dunst-project/dunst/pull/864), but I didn't think it was fast enough for some use cases. In a big icon theme the lookup would take ~0.15 seconds. Caching might alleviate those issues a little, but not enough.
Instead I wrote an icon lookup implementation based on parsing index.theme (https://github.com/dunst-project/dunst/pull/947). It only looks for icons of the right size according to index.theme and returns the result in about 1ms on the same hardware. This way caching isn't really necessary, since it should be possible to find the icon in sub 1 frame in most configurations. I did implement very simple caching by transferring the icon buffer to the new notification if it gets replaced (which is very common for volume notifications).
Would this be useful to mako as well?
Thanks for the feedback. Would need to investigate which is simpler, the current code + a cache, or parsing index.theme.