iris: streaming a transcript event no longer rebuilds the whole screen

Every client (bench_client, transcript_client, desktop-app) refolded and
rebuilt the ~3,200-row widget tree from scratch per SSE event, which is
the streaming-phase cost the P0 benchmark gate would otherwise measure
against a Compose app that updates one row. iris::widget::List gains
replace_back (swap the last row's widget in place, keeping its slot so a
pinned list stays pinned) and clear (the full-rebuild fallback);
transcript_ui::TranscriptScreen::apply diffs the folded row lists and
picks the cheapest update -- unchanged, append, replace-the-last-row, or
(rare regroup) a full rebuild, counted. TextEditCtx::set_with_spans lets a
row's text and span list land together on a streamed update.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

iris/android-app/src/bench_client.rs

@@ -4,17 +4,21 @@
 //! `transcript-ui`'s real screen with no server -- a frame-time comparison
 //! that measures the renderer rather than the data or the network.
 //!
-//! **Reuses `transcript_client.rs`'s shape** (folded items, a full
-//! `transcript_ui::build_tree` rebuild per event) with the network half
-//! replaced by the checked-in fixture, embedded with `include_str!` --
-//! `app/bench-fixture/assets/transcript.jsonl`, 1,915,760 bytes, generated
-//! by `app/bench-fixture/generate.py` and never a real transcript (that
-//! file's own README). The first 3,200 lines are the opening backlog,
-//! folded once through `client_core::transcript_fold::fold_page` exactly
-//! as a real `/transcript` page would be; the remaining ~400 are the
-//! streaming tail, replayed one at a time through `fold_event` -- the same
-//! fold path a live SSE reply arrives on -- by the "Run benchmark"
-//! control below.
+//! **Reuses `transcript_client.rs`'s shape** (folded items, the same
+//! `TranscriptScreen::apply` incremental update on every event) with the
+//! network half replaced by the checked-in fixture, embedded with
+//! `include_str!` -- `app/bench-fixture/assets/transcript.jsonl`,
+//! 1,915,760 bytes, generated by `app/bench-fixture/generate.py` and never
+//! a real transcript (that file's own README). The first 3,200 lines are
+//! the opening backlog, folded once through
+//! `client_core::transcript_fold::fold_page` exactly as a real
+//! `/transcript` page would be (then a full `transcript_ui::build_tree`,
+//! same as any first load); the remaining ~400 are the streaming tail,
+//! replayed one at a time through `fold_event` -- the same fold path a
+//! live SSE reply arrives on -- by the "Run benchmark" control below.
+//! Streaming through `apply` rather than a full rebuild per event is what
+//! this file exists to measure -- see docs/RUST.md's P0 box for the
+//! before/after report.
 
 use crate::bench_jni::PlatformHandle;
 use android_view::jni::{JavaVM, objects::GlobalRef};
@@ -344,8 +348,15 @@ impl BenchClient {
             let mut sent = 0usize;
             for event in stream_tail.into_iter().take(total) {
                 ctx.update(move |state: &mut BenchClient, rsc| {
+                    let old_items = state.items.clone();
                     state.items = fold_event(&state.items, &event);
-                    state.rebuild_transcript(rsc);
+                    match &state.screen {
+                        // The path P0 asked to measure: update only the
+                        // row(s) that changed instead of rebuilding all
+                        // ~3,200 of them per event.
+                        Some(screen) => screen.apply(rsc, &old_items, &state.items),
+                        None => state.rebuild_transcript(rsc),
+                    }
                 });
                 redraw.request_redraw();
                 sent += 1;

iris/android-app/src/transcript_client.rs

@@ -20,14 +20,22 @@
 //! **Reuses `iris/desktop-app`'s `app.rs` shape almost exactly** --
 //! `fold_event`/`group_tool_runs`/`fold_page`/`raw_seq` from
 //! `client_core::transcript_fold`, a `generation` counter guarding against
-//! a stale background response, and a full rebuild of the widget tree on
-//! every event (same tradeoff, same reason: `push_row` cannot update a row
-//! already on screen, and this rig's conversations are small). What
-//! differs is only the redraw mechanism: android-view has no
-//! `winit::EventLoopProxy`, so this uses `iris::task::Tasks::redraw_handle`
-//! (new, added alongside this box) to request a frame after each
-//! `TaskCtx::update` instead of relying on `Tasks::spawn`'s single
-//! end-of-future redraw -- see that method's own doc for why.
+//! a stale background response. What differs is only the redraw
+//! mechanism: android-view has no `winit::EventLoopProxy`, so this uses
+//! `iris::task::Tasks::redraw_handle` (new, added alongside this box) to
+//! request a frame after each `TaskCtx::update` instead of relying on
+//! `Tasks::spawn`'s single end-of-future redraw -- see that method's own
+//! doc for why.
+//!
+//! **Streaming no longer costs a full rebuild** (fixed after the P0 gate
+//! showed why it mattered -- 20 events/second means 20 rebuilds/second of
+//! a ~3,200-row transcript otherwise): `apply_event` calls
+//! `transcript_ui::TranscriptScreen::apply` with the item list before and
+//! after `fold_event`, which updates only the row(s) that actually
+//! changed (almost always just the one open assistant message) instead of
+//! refolding and rebuilding every row. `rebuild_transcript` still runs
+//! the whole widget tree once, for the opening page and for `apply`'s own
+//! rare regroup fallback.
 
 use client_core::api::{ApiClient, UreqTransport};
 use client_core::event_stream::{StreamItem, follow_session_events};
@@ -360,8 +368,17 @@ impl TranscriptClient {
     }
 
     fn apply_event(&mut self, rsc: &mut AndroidRsc<Self>, event: &SeqEvent) {
+        let old_items = self.items.clone();
         self.items = fold_event(&self.items, event);
-        self.rebuild_transcript(rsc);
+        match &self.screen {
+            // The common path: update only the row(s) that actually
+            // changed instead of refolding and rebuilding all ~3,200 of
+            // them per event (RUST.md's P0 streaming-phase fix).
+            Some(screen) => screen.apply(rsc, &old_items, &self.items),
+            // No screen yet (the opening page hasn't landed) -- build one
+            // the ordinary way once it has.
+            None => self.rebuild_transcript(rsc),
+        }
     }
 
     fn send_message(&mut self, session_id: String, text: String) {