Display application icon about tofi

[philj56]

Hi, not so far. The main problem is still as written above; I don't think there's a good way to make this quick. I do plan on having a more detailed look into this at some point, as it may not be as slow as I thought (especially SVG rendering, a random set of benchmarks suggest that resvg could be fast enough). There's other, easier improvements to make first though.

[philj56]

Not dumb at all 🙂. I think if this was to be done, lazy loading would be the most likely way. Compared to the current ~2-20ms startup time for the Harfbuzz backend, loading icons will probably always be much slower (though I still haven't got round to looking at this in more detail).

The main problem with that is just complexity. For context, at an extremely simplified level, tofi's architecture is pretty much:

initialise_everything();
while (true) {
    wait_for_keypress();
    handle_keypress();
    render();
}

Everything is single-threaded, as just the time taken to spawn and join new threads makes them not really worth it at the 1-2ms level.

The dependencies are split into a few categories:

• Drawing (Cairo)
• Text rendering (FreeType, HarfBuzz, Pango)
• Wayland (libwayland, xkbcommon)
• Miscellaneous (GLib - already required by Cairo / Pango / Harfbuzz)

To add lazily-loaded icons implies a few things:

• Logic to find and load icons (quite complicated as mentioned above, but not too bad)
• At least some level of multi-threading (probably just a single extra thread loading & passing icons back to the main thread)
• Dependence on an SVG library (libpng is "free", as it's already depended upon by FreeType / Cairo)

None of these are show-stoppers, but altogether it implies a fair amount of extra complexity. Combined with the fact that icons will never be as fast as the rest of tofi, they're pretty low on my priority list. I do still plan on giving them a more thorough go at some point though, as I understand the demand is fairly high (I guess it's the biggest feature that tofi's missing compared to rofi).

[philj56]

I knew someone would ask eventually 😄 I'll look into it, but I don't know how long it'll take. Thankfully the Icon Theme Specification provides some pseudocode showing the algorithm to use to find an icon, so maybe it won't be so bad.

[philj56]

Ok, so this has turned out to be much more complicated than I'd feared. There's a combination of factors:

• The icon theme spec is really quite complex.
• The icons apps provide are inconsistent, so I'd have to implement both SVG rendering with librsvg and scaling of PNGs to not have missing icons.
• The real killer: there's no good way to cache the necessary icons, as these can change e.g. every time you change your tofi config or switch to a different monitor. Without caching, the lookup will be very slow every time, which goes against the nature of tofi. Even in rofi, which is generally an order of magnitude (or more) slower to startup, icon loading is delayed until after startup, causing pop-in and more complexity.

Given all that, and the fact that I never used to use them in rofi anyway, I'm gonna abandon icons for now, though I may come back to it or look at it when I've got nothing else to do.

[timsofteng]

Hello. Any news about this feature?

[616b2f]

@philj56 how about lazy loading the icons? So we show the list of results first with a placeholder for icon (so it does not change width and high of the list items when they are loaded) and load the icons when there are ready.

Is that possible or are there other things that will not allow this approach?

I am new in that space so sorry if it's a dumb question.

[bbusse]

Maybe put the extra complexity in a seperate tool like tofi-thumbnailer. It could produce png from svg so that there is no extra dependency within tofi. It would also address the performance issue

[bbusse]

For icons in general one can always use font awesome or some unicode icons but then the assignment has to be done manually