[BUG] Icons that fail to load once are never retried, leaving permanently blank grid cells
Rofi version (rofi -v or git commit in case of build issue)
rofi-git 2.0.0.r77.g108f4948-1
Configuration
https://gist.github.com/kbuckleys/ebe7c9d29115729bb219db65b70391a2
Theme
https://gist.github.com/kbuckleys/84da15cf80bf3dfe1988e415da414ce6
Timing report
No response
Launch command
-dmenu with \0icon\x1f<absolute path> rows
Step to reproduce
The failure is intermittent — it arrives in bursts — so this is a recipe that produced it rather than one that produces it every time. It reproduced 6 times in the first 11 runs of a session and then stopped, with ~30 subsequent runs clean including several under heavy CPU and I/O load.
- Build a dmenu input file of 50 rows, each
<name>\0icon\x1f<absolute path to a 300x300 JPEG>, with 50 distinct images. - Use a grid theme:
listview { columns: 5; lines: 3; flow: horizontal; }withelement { orientation: vertical; children: [ element-icon, element-text ]; }andelement-icon { size: 150px; }. - Run with the window opening past the first viewport:
rofi -dmenu -theme grid.rasi -markup-rows -markup -format i -no-custom \
-l 3 -selected-row 37 < entries.txt- Scroll down to the end and back up to the top.
Observed: several cells draw their label with no image. In one captured frame, 6 of the 15 visible cells at the top of the list were blank while their labels rendered normally. The same files render in every cell on a run that opens at -selected-row 0.
Measurements
Scored by cropping the window and comparing, per grid cell, the standard deviation of the icon area against the label strip beneath it — a cell counts as failed only when the label is drawn and the icon area is flat. Same 50 covers, same flags, same session:
| case | worst blank cells in a frame |
|---|---|
-selected-row 0 |
0 |
-selected-row 5 (still within the first viewport) |
0 |
-selected-row 15 |
5 |
-selected-row 37 |
6, 6, 6 |
-selected-row 49 |
3 |
-selected-row 37, all 50 rows pointing at one image |
0 |
15 rows total, -selected-row 10 |
0 |
-threads changes it, which is consistent with the icon fetcher sharing the global pool that -threads sizes (source/view.c, g_thread_pool_new_full(..., config.threads, FALSE, ...), with 0 resolving to MIN(sysconf(_SC_NPROCESSORS_CONF), 128) — 6 on this 6-core machine). Measured while the bug was reproducing, at -selected-row 37:
-threads |
worst blank cells |
|---|---|
| default (6) | 6 |
| 2 | 10 |
| 1 | 11 |
Higher values were only tested after the burst had stopped, so I cannot claim they help; I include the downward direction because it is measured and it points at the pool.
Expected behavior
The expected behavior is for rofi to simply never fail a render, especially in large grids
Actual behavior
As explained earlier, inconsistent icon renders
Additional information
Two small changes would make a transient failure self-correcting:
- Set
query_started = TRUEonly afterg_thread_pool_pushsucceeds, and check theGErrorrather than passingNULL. - Reset
query_started = FALSEon the worker's failure paths (missing file,gdk_pixbuf_new_from_file_at_scalereturningNULL) so a laterrofi_icon_fetcher_queryfor the same entry re-queues it.
A retry cap per entry would keep a genuinely dead path from being retried on every redraw.
Notes
The paths handed to rofi are absolute, exist before the process starts, and are plain 300x300 baseline JPEGs of 25–62 KB. They were verified independently with ImageMagick before each run, and the application generating the list has its own log confirming it emitted a real path (not a placeholder) for every row of every affected draw.
I've checked if the issue exists in the latest stable release
- Yes, I have checked the problem exists in the latest stable version
Source: davatorium/rofi