davatorium / rofi

Rofi: A window switcher, application launcher and dmenu replacement
https://davatorium.github.io/rofi/
Other
13.03k stars 609 forks source link

[BUG] Icons in script mode takes a small delay before rendering #1668

Closed kriansa closed 2 years ago

kriansa commented 2 years ago

Rofi version (rofi -v)

Version: 1.7.3-123-g8e8765e2

Configuration

Default one, or -no-config

Launch command

rofi -modi myscript:./script.sh -show myscript -show-icons

Step to reproduce

Expected behavior

I see both the text (Option 1, Option 2...) and the icons showing up at the same time

Actual behavior

I see a small delay before the icons are displayed. You can re-run the command several times and you will notice that.

Additional information

Oddly enough, this seems to be caused by the rendering of SVGs. If you replace in the two last lines of the script, $svg by $png and re-run the script, you will see it rendering instantly, but if there's at least one SVG in the list then that delay starts showing up.

kriansa commented 2 years ago

Hi @DaveDavenport, I noticed this issue was tagged as incomplete request, I apologize for that mistake. If it was because no config was provided, it was because none is needed and the default one (or -no-config) is sufficient to reproduce the issue.

Nonetheless I have provided the one being used (the default one). Let me know if this is still incomplete.

DaveDavenport commented 2 years ago

The issue template very explicitly asks to provide information, it does this for a good reason. So if not provided it will get marked as 'incomplete'. I am not sure how I can make this more clear in the template. I try to be consistent in enforcing this.

Anyway this is not a bug but intended behavior. Loading icons is slow (lookup an icon possibly via icon-theme, rendering it (svg is in general slow-ish), scaling etc.). Especially with SVG rendering an icon depends on the SVG complexity and can take extremely long. You noticed this yourself in your issue. (that png is near instant, svg slower).

Therefor rofi loads the text directly, icons are done via a threading pool in the background and the view is reloaded once an icon is rendered onto a surface and can be displayed. Making it wait till icon loading is done before displaying will be very annoyingly slow.

kriansa commented 2 years ago

Thanks for the details. It is indeed a very minor annoyance, I just find it weird that I don't see that issue when I run rofi -no-config -show drun -show-icons -icon-theme Papirus, where all icons are SVGs.

The issue template very explicitly asks to provide information, it does this for a good reason. So if not provided it will get marked as 'incomplete'. I am not sure how I can make this more clear in the template. I try to be consistent in enforcing this.

Don't worry about that, the template is good enough already. It's just that I tried to make the reproduction steps as minimal as possible, so I omitted that in an attempt to save time, that's my bad.

DaveDavenport commented 2 years ago

Thanks for the details. It is indeed a very minor annoyance, I just find it weird that I don't see that issue when I run rofi -no-config > -show drun -show-icons -icon-theme Papirus, where all icons are SVGs.

And that is exactly why it is async, you never know before hand how long it takes to load.

kriansa commented 2 years ago

I see, but the delay is consistent on one command (script mode) while inexistent on the other (drun mode), when both are loading the exact same icon size and format (SVG).

DaveDavenport commented 2 years ago

both of them use rofi_icon_fetcher_query, https://github.com/davatorium/rofi/blob/next/source/modes/drun.c#L1332 and https://github.com/davatorium/rofi/blob/next/source/modes/script.c#L446

So I cannot directly explain it. (papirus does ship different sizes svg, the 'icon-theme' way will pick the closest size one. I assume smaller icons are also less detailed? are you passing the same size?)

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.