The swipe-up-dismiss + relaunch bug (process survives, activity
re-creates) crashed or left a sparse grid. Root cause chain, fully
documented in docs/BUGS/recreation-stale-textures.md:
- Each android_main (per activity instance) is a fresh Slint world with
a fresh wgpu device (i-slint-core context is thread-local); the old
world zombie-parks (Slint 1.18 android backend never delivers
TerminateWindow/Destroy to it).
- Worker-side GPU uploads + a process-global loader let textures cross
world/device boundaries: a texture destroyed with its device left a
stale handle in the registry (wgpu-core assert in transition_resources
on the render thread) — either killing the process, or, with the
interim catch_unwind band-aid, keeping a poisoned world alive and
corrupting the VISIBLE world's imports (the sparse grid). A/B against
pristine Slint confirmed the mechanism (pristine: 1 self-killing panic
per recreation + full grid).
Fix:
- gputex rewrite: workers deliver plain RGBA8; the UI drain tick
uploads to the device captured from the rendering notifier
(Slint's borrowed-resource contract). Staleness impossible by
construction. Keepalive thread removed.
- Per-world lifecycle: CURRENT_WORLD gate silences zombie ticks;
re-init invalidates the dying device + swaps the engine; render
notifier handles RenderingTeardown/RenderingSetup (in-place cell
clear — never set_vec mid-render, which desyncs the for-loop).
- Vendor patch surface reduced to the single final-flush hunk
(catch_unwind guard reverted to pristine).
Slint's android-activity backend wakes the main loop from a dedicated
"slint vsync" Choreographer thread while any animation is active
(i-slint-backend-android-activity/vsync.rs). Android schedules that
thread at nice +10 (lowest on device), while our 4 turbojpeg workers
inherited the UI thread's nice -10. Under CPU bursts the +10 waker
starves and the main loop's next wakeup lands 3-4 frames late: 25-33 ms
of pure wake latency at 120 Hz, with zero cost in our tick (d=7-34 us) —
exactly the phone stall signature (measured: 28-39 ms gaps, catch-up
events).
- prio module: setpriority FFI (self + by-tid), raise_slint_vsync()
- thumb workers + dispatcher: nice +2 at spawn (ahead of background
apps, behind the UI's -10)
- android_main: prio-fix thread raises "slint vsync" to nice 0 with a
readback log
- verified on emulator: thumb-* hold nice 2, slint vsync holds 0 while
foreground (Android re-nices backgrounded processes — expected)
- emulator scroll cadence unchanged (llvmpipe rasterization ceiling,
not a priority issue) — phone is the acceptance target, A/B test
planned for when it is back online
Also: drop unused android_logger dependency (nblog replaced it).
- scan.rs: recursive walk of Pictures/DCIM (GALLERY_SCAN_DIRS override),
image-ext detection, mtime/size capture, no symlink-dir following
- db.rs: rusqlite(bundled) store; incremental apply (insert/update/delete)
keyed on path with mtime/size change detection; derived columns reset on
change; Android DB path in Android/data/<pkg>/files (EXTERNAL_DATA_DIR is
unset in this NativeActivity setup)
- lib.rs: start_scan() background thread -> invoke_from_event_loop ->
VecModel + status line; called from desktop and Android entry points
- main.slint: ListView of paths (M1), status line with scan stats
- main.rs: fix desktop bin for 1.18.1 (no slint::Result; ComponentHandle)
- build.sh: export NDK clang CC_/CXX_/AR_ per target (bundled sqlite)
- tests: 5k-file scan < 2s, incremental apply, roundtrip
Verified on emulator: 5002 files in 153-226 ms; relaunch 0+ 0~ 0-;
touch -> 1~, delete -> 1-.
