Tags: usamaabid/hyperframes
Tags
Merge branch 'main' into fix/electron-nested-iframe-raf-tick Resolves conflicts in packages/player/src/hyperframes-player.ts introduced by main's LOC-split refactor (PR heygen-com#750), which extracted DirectTimelineClock + ParentMediaManager into separate modules. The PR's parent-tick-clock additions are re-applied on top of the refactored class structure: - New `_parentTickRaf` field - New `_startParentTickClock` / `_stopParentTickClock` private methods (placed alongside `_sendControl`, since the tick uses postMessage) - `_stopParentTickClock()` call added to `disconnectedCallback`, `pause`, `seek`, and `_onIframeLoad` (alongside the existing `this._directTimelineClock.stop()` calls there) - `play()` updated: - `this._paused = false` moved BEFORE `_startParentTickClock` so the RAF tick's `_paused` check doesn't self-terminate on first callback - `_startParentTickClock()` only fires on the runtime-bridge path (`!directTimelineStarted`) AND when ready + no adapter, matching the second PR commit's review fix No semantic change vs. the pre-refactor PR head — this commit only reconciles the surface differences from heygen-com#750. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
chore: release v0.6.2 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
chore: release v0.6.1 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
fix(player): drive composition ticks from widget-frame rAF via postMe… …ssage (heygen-com#739) * fix(player): drive composition ticks from widget-frame rAF via postMessage Chromium throttles requestAnimationFrame in deeply nested cross-origin iframes. In Claude desktop (Electron), the composition iframe's own rAF loop stalls, so GSAP is never seeked and animation freezes even when TransportClock.isPlaying() is true. The correct fix is to drive ticks from the widget-frame rAF, which lives one level up and is not subject to the same throttling. When play() takes the runtime bridge path (no direct timeline adapter), the player now starts a parent-frame rAF loop that sends "tick" postMessages to the composition iframe on every frame. The runtime's control bridge handles "tick" by calling seekTimelineAndAdapters(clock.now()) if the clock is playing — identical to what transportTick does on each rAF, just driven from outside. The composition iframe's own rAF loop is unchanged and keeps running normally in standard browsers. Seeking GSAP twice per frame is idempotent, so there is no regression on claude.ai or any other non-throttled environment. Co-Authored-By: Claude Sonnet 4.6 <[email protected]> * fix(player): address review issues in parent tick clock - _paused must be false before _startParentTickClock runs; otherwise the first RAF callback sees _paused=true and self-terminates immediately - Guard _startParentTickClock behind this._ready && !this._directTimelineAdapter so tick messages aren't sent into an uninitialized iframe when play() is called before the composition probe has resolved - Add clock.reachedEnd() check to onTick so end-of-composition handling (pause, seek-to-end, postState) runs even when the composition iframe RAF is fully throttled - Stop the parent tick clock in seek() alongside _stopDirectTimelineClock to avoid burning CPU frames while paused after a scrub - Add onTick to bridge.test.ts createMockDeps() and add a dispatch test Co-Authored-By: Claude Sonnet 4.6 <[email protected]> * chore: bump versions to 0.6.5-alpha.0 for testing Co-Authored-By: Claude Sonnet 4.6 <[email protected]> --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]>
PreviousNext