mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-14 18:01:20 +08:00
Miguel Angel Simon Sierra
4e4776d6ca
Opening a project ran up to three whole-document scans per clip. The manifest identifies clips with `stableClipId` (`el.id` OR `data-hf-id`) while the studio lookup asked `getElementById`, which never matches the second half — so every hf-id clip missed the fast path and fell through to `getTimelineDomNodes`, a fresh `[data-start]` scan whose `isTimelineIgnoredElement` filter walks `closest()` over every node. At 3,000 clips that is 37M ancestor walks rejecting nothing. Build one index per `processTimelineMessage` pass and thread it to all three emitters: node resolution, the source-scoped selector-occurrence index, and the composition branch that re-resolves a host when the manifest carries no `compositionSrc`. The index is derived from a single document walk and is discarded with the pass, so an edit that mutates the preview DOM cannot resolve against stale nodes. Identity is unchanged. `usedNodes` claiming still runs through the resolver, the existing `data-composition-id` / class / attribute-match fallback chain is intact for clips the index cannot resolve, the source file of an element is derived to match `closest()` exactly, and `getSourceScopedSelectorIndex` keeps its indexless signature for callers that have no index. The load-bearing test runs the FULL derivation twice over a generated 3,000-clip project — node resolution included, not a pre-resolved host — and asserts every `id` and `key` is byte-identical, covering the clips whose `clip.id` is null. A divergence there would silently drop selection, expanded state, the keyframe cache and lint findings.