Fold blocking texture-export note into todo.md #10

The editor-freeze-on-export is the existing TODO #10 (background texture IO).
Sharpen #10 with the concrete site and the finding that the readback binding
(`gfx().read_pixels`) already exists — so it needs no engine work, just an
off-thread encode, tiled to avoid OOM on large maps. Trim the code comment to
a pointer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: gajop

docs/porting/todo.md

@@ -343,10 +343,23 @@ in particular can stall the editor for a noticeable time.
 **How (sketch).** Split the GPU part from the CPU part: do the minimal on-thread
 GL work to get the pixels off the GPU (readback into a CPU buffer), then hand the
 CPU-side encode + file write to a background worker (the same off-thread IO path
-grass/metal/heightmap use). Needs a way to read a texture's pixels into a plain
-buffer on the engine thread, after which the ops become "readback (on-thread) →
-encode+write (off-thread)". Investigate whether a shared background
-rendering/IO context is feasible for the readback itself.
+grass/metal/heightmap use). The ops become "readback (on-thread) →
+encode+write (off-thread)".
+
+**Concrete site + finding (2026-07-21).** The blocking path is
+[textures/project.rs](../../native/src/sbc/textures/project.rs) `export_map_textures`
+→ `export_diffuse`/`export_shading_textures` → `save_texture_png`
+([graphics.rs](../../native/src/sbc/textures/model/texture_model/graphics.rs)),
+which calls the engine's `gfx().save_image` — one blocking call that reads the GL
+texture *and* encodes+writes the PNG on the draw thread, freezing the editor for
+the whole export (user-observed several-second stall). The readback binding
+already exists: `gfx().read_pixels(x, y, w, h, format) -> (Vec<f32>, format)`, and
+`io::write::save_png` already encodes off-thread (metal/grass/heightmap use it).
+So no engine work is needed — just: read pixels on the draw thread, encode in an
+`IoJob`. Two cares: (1) convert the `f32` channels back to `u8`; (2) **tile the
+readback** — a full-map diffuse as `read_pixels`' f32 RGBA is ~1 GB at 8K, so a
+whole-texture buffer would OOM on large maps. That tiling is why this is its own
+careful effort, not a quick swap.
 
 ## 11. Texture model uses `RefCell` — remove the runtime-panic surface
 

native/src/sbc/textures/project.rs

@@ -44,15 +44,9 @@ fn load_textures(ctx: &mut Context, paths: &ProjectPaths) {
     log_result("load textures", &dir, result);
 }
 
-// TODO(perf): these run on the draw thread and freeze the editor during export.
-// `save_texture_png` calls the engine's `gfx().save_image`, which reads the GL
-// texture AND encodes+writes the PNG in one blocking call. The heightmap/metal/
-// grass exports already encode off-thread (`*::jobs::export`); the diffuse and
-// shading textures should too: read the pixels on the draw thread via
-// `gfx().read_pixels` (only the GL read must be here), then hand the buffer to an
-// IoJob that encodes with `io::write::save_png`. Do it in tiles — a full-map
-// diffuse read back as `read_pixels`' f32 RGBA is ~1 GB at 8K, so a naive
-// whole-texture buffer would OOM on large maps.
+// These `save_texture_png` calls block the draw thread (GL read + PNG encode in
+// the engine's `save_image`), freezing the editor during export. Moving the
+// encode off-thread is docs/porting/todo.md #10.
 fn export_map_textures(ctx: &mut Context, output_dir: &Path, _options: &MapExportOptions) {
     let interface = *ctx.interface;
     let diffuse = output_dir.join("diffuse.png");