Mini-map tiles sometimes white until the map texture is opened (failed/stuck tile fetch not retried?) #436

New issue

Closed

opened 2026-10-05 12:56:23 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-05 12:56:23 +00:00

Owner

Map tiles in the mini-map (People window → Nearby, and the floating mini-map) are sometimes solid white. Opening the map / the tile texture fixes them, which suggests the tile's download or decode failed (or was never requested at a usable priority) and nothing retried it until something boosted that texture. Owner report, 2026-10-05.

Evidence

The UI layer logs #VKWhite resolveTexture -> white: ... raw=0 rawdata=0 raw_wh=-1x-1 img_wh=1x1 comps=0 discard=-1 (llrendervkbackend.cpp ~705) whenever it draws an image with no data. Many such lines appear in a session; the log stops after 64 distinct images, so we can't yet tell which are map tiles.
"Opening the map texture fixes it" is consistent with a boost / refetch of a texture that was stuck at no data (discard=-1).

Suspects

Fetch failure without retry: map tiles come from the map server (LLWorldMipmap / LLNetMap / LLViewerRegion map image). If the HTTP fetch fails (timeout, 404 for a tile that isn't generated yet, CDN hiccup), the texture may be marked missing / failed and never re-requested. Check LLTextureFetch handling for map tiles (FTT_MAP_TILE), setMissingAsset / isMissingAsset, and how the world map / minimap request tiles (priority, boost level).
Decode or priority starvation: tiles requested at a low boost/priority while the region loads, then their priority never rises (the minimap is small, so its demand may compute as tiny), leaving them at no data. Opening the big map bumps the priority.
UI texture idle release (new, #405 UI work): UI textures not drawn for 30 s release their VRAM and are re-uploaded from the CPU copy when drawn again. If a map tile's CPU copy was trimmed or never kept (thumbnail policy, markVKUiUsed), the re-upload has no data → white. Check whether the white tiles correlate with switching away from / back to the People window or mini-map.
Map tile texture ownership: map tiles may be drawn by the UI path (LLRenderVK) while their LLViewerFetchedTexture is also subject to world-texture discard/trim logic.

To do

Log (rate-limited, behind a debug flag) when a minimap / world-map tile is drawn white: tile region / grid coords, texture id, fetch state (missing / failed / pending / decoded discard), boost, last fetch error.
Add a retry with backoff for failed map-tile fetches (and for tiles stuck at no data while visible), and give visible minimap tiles a sensible priority.
If it's the UI idle-release path: never evict a UI texture whose data can't be re-uploaded, or keep the CPU copy for map tiles.
Repro: log in, keep the People window / mini-map open, teleport a few times, and toggle the window; watch for white tiles.

Done when

White mini-map tiles recover on their own (retry), or don't happen; the cause is identified from the new logging.

Map tiles in the **mini-map** (People window → Nearby, and the floating mini-map) are sometimes **solid white**. Opening the map / the tile texture fixes them, which suggests the tile's download or decode failed (or was never requested at a usable priority) and nothing retried it until something boosted that texture. Owner report, 2026-10-05. ## Evidence - The UI layer logs `#VKWhite resolveTexture -> white: ... raw=0 rawdata=0 raw_wh=-1x-1 img_wh=1x1 comps=0 discard=-1` (`llrendervkbackend.cpp` ~705) whenever it draws an image with no data. Many such lines appear in a session; the log stops after 64 distinct images, so we can't yet tell which are map tiles. - "Opening the map texture fixes it" is consistent with a **boost / refetch** of a texture that was stuck at no data (`discard=-1`). ## Suspects 1. **Fetch failure without retry:** map tiles come from the map server (`LLWorldMipmap` / `LLNetMap` / `LLViewerRegion` map image). If the HTTP fetch fails (timeout, 404 for a tile that isn't generated yet, CDN hiccup), the texture may be marked missing / failed and never re-requested. Check `LLTextureFetch` handling for map tiles (`FTT_MAP_TILE`), `setMissingAsset` / `isMissingAsset`, and how the world map / minimap request tiles (priority, boost level). 2. **Decode or priority starvation:** tiles requested at a low boost/priority while the region loads, then their priority never rises (the minimap is small, so its demand may compute as tiny), leaving them at no data. Opening the big map bumps the priority. 3. **UI texture idle release (new, #405 UI work):** UI textures not drawn for 30 s release their VRAM and are re-uploaded from the CPU copy when drawn again. If a map tile's CPU copy was trimmed or never kept (thumbnail policy, `markVKUiUsed`), the re-upload has no data → white. Check whether the white tiles correlate with switching away from / back to the People window or mini-map. 4. **Map tile texture ownership:** map tiles may be drawn by the UI path (`LLRenderVK`) while their `LLViewerFetchedTexture` is also subject to world-texture discard/trim logic. ## To do - Log (rate-limited, behind a debug flag) when a minimap / world-map tile is drawn white: tile region / grid coords, texture id, fetch state (missing / failed / pending / decoded discard), boost, last fetch error. - Add a **retry with backoff** for failed map-tile fetches (and for tiles stuck at no data while visible), and give visible minimap tiles a sensible priority. - If it's the UI idle-release path: never evict a UI texture whose data can't be re-uploaded, or keep the CPU copy for map tiles. - Repro: log in, keep the People window / mini-map open, teleport a few times, and toggle the window; watch for white tiles. ## Done when - [ ] White mini-map tiles recover on their own (retry), or don't happen; the cause is identified from the new logging.

sky_line added the

bug

labels

2026-10-05 12:56:23 +00:00

sky_line added this to the Slipstream project

2026-10-06 15:04:14 +00:00

sky_line added the

status

testing

label

2026-10-06 15:57:10 +00:00

sky_line referenced this issue from a commit