fix: desktop scenes can render black — reveal clip only after a painted frame - #8
Open
patrobinsonai wants to merge 1 commit into
Open
fix: desktop scenes can render black — reveal clip only after a painted frame#8patrobinsonai wants to merge 1 commit into
patrobinsonai wants to merge 1 commit into
Conversation
…ed frame, prime on all platforms On desktop the engine swapped the still poster for the video on the first 'seeked' event and never primed playback. A muted video that has never played does not reliably paint a frame on seek (the same quirk the mobile path already guards against), so desktop visitors could get a black stage while the scrub logic ran on happily underneath. - reveal .has-clip via requestVideoFrameCallback (an actually painted frame) when available, falling back to 'seeked' where rVFC is missing - primeVideo() no longer bails on desktop; loadeddata primes immediately on fine-pointer devices (muted autoplay is permitted there), keeping the existing first-gesture priming on touch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
On desktop,
loadClip()addshas-clip(hiding the still poster) on the video's firstseekedevent, andprimeVideo()explicitly bails when!isMobile(). But a muted video that has never played doesn't reliably paint a frame on seek — the exact quirk the mobile path already guards against with poster-until-paint + first-touch priming. When a desktop browser hits this, the poster is hidden, the video stays unpainted, and the visitor sees a black stage while the scrub logic runs on happily underneath.Repro
Build any world, open it in a desktop Chromium context where seek-to-paint doesn't kick in before the first
seeked(embedded Chromium/webviews hit it consistently; standard Chrome can hit it during first-load blob buffering). Scroll: sections go dark instead of scrubbing.The fix (4 lines)
has-clipviarequestVideoFrameCallback— i.e. only once a frame has genuinely painted — with the previousseekedlistener kept as the fallback for browsers without rVFC.primeVideo()run everywhere, and prime onloadeddatafor fine-pointer devices (muted autoplay is permitted on desktop; touch keeps the existing first-gesture priming).Verified on two production builds (5-scene and 4-scene chains, architecture A): desktop black-stage gone, mobile behaviour unchanged, reduced-motion path untouched.