From ec9fd7c18983ad042cfb11f2cd039ad42657efac Mon Sep 17 00:00:00 2001 From: Greg Pomerantz Date: Wed, 28 Oct 2026 21:10:55 -0400 Subject: [PATCH] docs: recreation fix verified on phone (Mali G715) --- docs/BUGS/recreation-stale-textures.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/docs/BUGS/recreation-stale-textures.md b/docs/BUGS/recreation-stale-textures.md index 95b1128..fa6b7be 100644 --- a/docs/BUGS/recreation-stale-textures.md +++ b/docs/BUGS/recreation-stale-textures.md @@ -1,8 +1,9 @@ # Activity recreation destroys GPU textures; worker-side uploads created stale handles -**Status:** FIXED 2026-10-28 (render-thread uploads + per-world lifecycle, -emulator-verified: 3+ dismiss/relaunch cycles, 0 panics, full grid). -Phone re-verification pending. +**Status:** FIXED 2026-10-28 (render-thread uploads + per-world lifecycle). +Verified on emulator (4+ recreation cycles) AND on the Pixel 9 Pro +(Mali G715): 3 worlds in one process, 0 panics, full grid every time, +scroll + scroll-back clean. ## Symptom @@ -119,10 +120,6 @@ sparse grid. The panic was the cleanup.) ## Open / follow-ups -- **Phone re-verification** (Mali G715): the UI-thread upload cost and - the recreation path on real hardware. Expectation: upload cost ≈ the - same `write_texture` work that used to happen on workers (now ~2/tick - on the UI thread, between frames). - **Zombie worlds** persist (Slint 1.18 android backend + android-activity 0.6.1 never deliver `Destroy` to the old app). They are now inert (tick gated, no shared state) but their threads +