- Ya
- 26 Agosti 2026, 03:58 UTC
- Mwandishi
- kamo
- Ahadi ya
- 5572590
The slideshow preloaded every wallpaper behind a single Promise.all, so nothing painted until the LAST image in the set had settled. On a tenant with a dozen backgrounds that meant bare background until the twelfth arrived — for a picture the slideshow does not need until 8x(N-1) seconds later. Every request still starts at once; going sequential would starve the crossfade, since image 2 has to be decoded before the first 8 s dwell is up. What changed is when the result is published: the decided PREFIX goes out as each image settles, so the first paint waits on image 1 alone. Which is the floor anyway — image 1 is the one shown first. Publishing a prefix rather than appending in completion order is what keeps this behaviour-identical. Order is preserved exactly as the old filter left it, and a 404 in the middle still drops out. Verified by simulation over 4,000 random pass/fail patterns and settle orders: the final array matches the old `urls.filter(...)` in every case, and 87% of them paint before the slowest image has settled. The cycle effect had to stop depending on `images`, or every append would tear down and restart the 8 s interval and the first wallpaper's dwell would keep resetting while the rest of the set arrived. It depends on `images.length >= 2` now and reads the live array through a ref at fire time, which is the same shape the order flag already used. Deliberately NOT done, and this is the half that fails the brief: rendering only the current and next image. That breaks the 1.6 s crossfade — the elements have to already be in the DOM at opacity 0 — and breaks shuffle, which reads the next index at fire time. All resolved images stay mounted. Verified: tsc --noEmit clean; all 10 guards pass; the background-order suite passes.