[Bug]: Appearance Environments section flickers when opening the drawer

[rosspeili]

AVATAR version

v0.4.0 (Windows installer)

How do you run AVATAR?

From source (npm run desktop)

OS

W11

Primary area

Appearance (avatars / environments)

What happened?

Opening Gear → Appearance → Environments sometimes causes a visible flicker or flash in the environments section — built-in GIF thumbs (Stars / Code / Bloom / None) or the scroll chrome repaint. Reported as intermittent (~1 in 10 drawer opens on some machines). Avatars section does not flicker the same way.

This section has no WebGL — only <img> GIF previews in the picker plus the glass drawer chrome (backdrop-filter). Built-in thumbs load full-size bundled GIFs (~32MB total; code.gif ~22MB) without loading="lazy" (the Custom grid uses lazy loading).

Expected behavior

Environments accordion opens smoothly: thumb previews and drawer chrome stay stable with no flash, blank frame, or visible repaint hitch.

Steps to reproduce

1. Launch AVATAR (installer or npm run dev:desktop).
2. Gear → Appearance → expand Environments.
3. Close the drawer or switch accordions (Avatars ↔ Environments); repeat several times.
4. Optional: toggle Custom expander if a custom Directories folder is configured.
5. Note occasional flicker on the built-in row or scroll area.

Console / error text (optional)

n/a — visual / compositor issue; no errors reported.

Screenshots / notes (optional)

• Repro is intermittent; a screen recording helps more than a single frame.
• Try overlay vs windowed, first open vs reopen, integrated GPU laptop.
• Parent context: avatar picker stall is separate ([Feature]: Performance pass on dual-canvas avatar / skin pickers #10 / PR perf(appearance): draw avatar thumbnails from images instead of live VRM previews #20).

Checklist

• I searched existing issues for a duplicate
• I redacted personal paths and sensitive names

[rosspeili]

Proposed investigation / fix

1. Profile when Environments accordion opens (image decode, layout, paint, composite layers).
2. Compare built-in row vs Custom grid (lazy) vs Color fade row (no GIF).
3. Isolate: disable drawer backdrop-filter; swap GIF thumbs for static PNG posters.Fix directions (pick what measurement supports):

• Static picker posters for built-ins (full GIF for stage only) — same idea as avatar thumbnails.
• loading="lazy" on built-in <img> thumbs.
• Smaller or re-encoded bundled GIFs for picker vs stage.
• Compositor hints (content-visibility, contain).

[AUDOSt0ck1ng]

Investigation update — main thread ruled out, new lead

I profiled this on Windows 11 with a dedicated GPU, running from source on main
(v0.5.0). I could not reproduce the flicker, so everything below is
measurement plus code reading, not a confirmed repro.

What the picker actually costs

The built-in thumbs render the full-size stage GIFs — the picker and the stage
share one URL (holoField.js:17, PalettePanel.jsx:139):

asset	size	pixels	frames	loop
stars.gif	2.2 MB	540×763	36	1.1 s
code.gif	20.8 MB	480×480	223	14.9 s
bloom.gif	7.8 MB	270×480	225	15.0 s

All three play into ~64 px boxes. While the accordion is open that is ~31 image
decode tasks per second; with it closed, zero — so 100% of the app's image
decoding comes from this picker. The accordion unmounts its body when closed
(PanelPrimitives.jsx:12), so every open remounts all three.

But none of it produces a stall

Recording 30 s while opening and closing the accordion ~10 times:

frames sampled   1800  (~60 fps)
frame interval   p50 16.7   p95 16.8   p99 16.8   max 17.0ms
long frames      0 over 20ms, 0 over 33ms
image decode     294 tasks, 362.4ms total (1.2% of the window)
decode duration  p50 0.81   p95 3.10   p99 8.42   max 19.62ms

Not one dropped frame across every mount, and the one 19.6 ms decode outlier did
not cost a frame either — image decode runs off the main thread. Cold remount
cost is ~30 ms for code.gif (21.8 ms fetch + 8.6 ms decode), about two frames.

So on this hardware the "expensive decode on remount" theory does not hold up.

Caveat on the blind spot: requestAnimationFrame samples the main thread. A
compositor- or raster-side artifact — layer discard, backdrop-filter cache
invalidation, GPU process — would not show up in any of these numbers. So this
rules out a main-thread stall, not the flicker.

The lead I would like to check first

loadLibraryEnvironments (userLibrary.js:88-98) reads every file in a
configured environments folder fully into renderer memory and converts it to a
blob URL — no cap, no thumbnailing, no laziness, and it happens when the folder
is configured rather than when the Custom expander is opened. Blob URLs pin
their bytes; unlike HTTP-loaded images Chromium cannot discard and refetch them.

A large custom folder would therefore hold hundreds of MB of non-discardable
memory, and sustained pressure is exactly what makes Chromium drop decoded image
frames — which would leave the built-in thumbs re-decoding on each open. That
fits the intermittency and the machine dependence, and it would explain why I
see nothing: I have no custom environments folder configured.

It also fits the asymmetry you noted. Avatars had this same class of problem and
it was fixed — see the note in MiniAvatar.jsx, where per-avatar live canvases
were replaced with static thumbnails cached to disk. Environments never got that
treatment.

Questions

1. Do you have a custom environments folder configured under Directories?
2. If so, roughly how many files, and how large is the folder in total?
3. Does the flicker still happen with Directories reset to the bundled defaults?

Question 3 is the decisive one — if the flicker survives with no custom folder,
this lead is wrong and the compositor path is where to look next.

[rosspeili]

Resource note (installer ~1 GB RAM baseline is mostly Chromium + VRM; this is the avoidable spike):

Built-in env thumbs still share the full stage GIFs (code.gif ~21 MB / ~223 frames, etc.). Opening Environments can decode hundreds of MB for ~64 px previews and keep decode CPU spinning while the accordion is open — same root as the flicker investigation.

Still prefer the fix directions already on this issue:

1. Static PNG posters for picker thumbs (stage keeps the animated asset)
2. Optionally re-encode / shorten stage GIFs (especially Code / Bloom) so stage decode isn’t huge either
3. loading="lazy" on built-ins as a small extra

That should cut both flicker risk and the RAM spike without touching the VRM path.