#2322·rofi

[BUG] Icons that fail to load once are never retried, leaving permanently blank grid cells

Author: kbuckleysCreated Aug 9, 2026Updated Sep 1, 2026
Labelsbug

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.

  1. Build a dmenu input file of 50 rows, each <name>\0icon\x1f<absolute path to a 300x300 JPEG>, with 50 distinct images.
  2. Use a grid theme: listview { columns: 5; lines: 3; flow: horizontal; } with element { orientation: vertical; children: [ element-icon, element-text ]; } and element-icon { size: 150px; }.
  3. Run with the window opening past the first viewport:
bash
rofi -dmenu -theme grid.rasi -markup-rows -markup -format i -no-custom \
     -l 3 -selected-row 37 < entries.txt
  1. 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:

  1. Set query_started = TRUE only after g_thread_pool_push succeeds, and check the GError rather than passing NULL.
  2. Reset query_started = FALSE on the worker's failure paths (missing file, gdk_pixbuf_new_from_file_at_scale returning NULL) so a later rofi_icon_fetcher_query for 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