Skip to content

feat(encode): incremental encoding for multi-view slide compositions#43

Merged
LeadcodeDev merged 1 commit into
mainfrom
feat/incremental-multiview
Jul 18, 2026
Merged

feat(encode): incremental encoding for multi-view slide compositions#43
LeadcodeDev merged 1 commit into
mainfrom
feat/incremental-multiview

Conversation

@LeadcodeDev

Copy link
Copy Markdown
Owner

Closes #23.

Goal: lift incremental re-encoding beyond views[0] of single-slide scenarios.

  • All-slide compositions (any view count) now segment into slots: one per scene plus one per inter-view transition, in exact build_frame_tasks order — locked by an equivalence test asserting concatenated per-slot tasks equal the full builder's output, with and without view transitions (the incremental stream may not differ from a full encode).
  • Pure, unit-tested planning: segment_slots / slot_hash / plan_dirty. A view-transition slot hashes both boundary scenes + the transition config, so changing the last scene of a view re-renders that scene and the transition into the next view (asserted: dirty = [false, true, true, false]).
  • Slot-layout changes vs the previous cache re-render everything (safe fallback); single-view scenarios keep identical slot layouts, so existing watch caches remain valid.
  • World views deliberately still refuse with a clear reason: camera pans composite several scenes per frame, so frames aren't scene-partitioned. Real per-scene surface caching is a separate performance project — the error message now says exactly that.

Tests: 5 new — 3 pure planning (enumeration order, full-builder equivalence, dirty propagation incl. layout-change fallback) + 2 integration (a 2-view composition that previously failed IncrementalUnsupported encodes twice with a strict subset re-rendered on run two; world views keep their explicit refusal). 222 total, all green.

Verify: cargo test --workspace → 222 passed ✓ · cargo fmt --check ✓ · clippy 0 warnings ✓

Incremental re-encoding was hardcoded to views[0] of single-slide
scenarios. It now segments any all-slide composition into slots —
one per scene plus one per inter-view transition, in exact
build_frame_tasks order (locked by an equivalence test):

- segment_slots / slot_hash / plan_dirty are pure and unit-tested;
  a view-transition slot hashes both boundary scenes + the transition
  config so it re-renders when either side changes
- the last scene of a view keeps the existing rule (re-render when
  the next scene changed and has an incoming transition)
- slot-count changes vs the previous cache fall back to a full
  re-render; single-view scenarios keep byte-identical slot layouts
  so existing watch caches stay valid
- world views still return IncrementalUnsupported with an honest
  reason: camera pans composite several scenes per frame, so frames
  aren't scene-partitioned (real per-scene surface caching is a
  separate performance project)
@LeadcodeDev
LeadcodeDev merged commit 0ff06be into main Jul 18, 2026
@LeadcodeDev
LeadcodeDev deleted the feat/incremental-multiview branch July 18, 2026 22:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat(encode): incremental encoding for world views

1 participant