Repository navigation
fix(browser): prepare actual SHM arrivals off Program (#802) - #816
Merged
Merged
Conversation
iamfatness
marked this pull request as ready for review
October 7, 2026 21:01
This was referenced Oct 7, 2026
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.
Refs #802.
Browser source SHM mapping/full BGRA copies previously ran on the render tick. With CPU preparation enabled, one bounded reader now owns mapping, seqlock copying and preparation outside the metadata lock; Program collects immutable descriptors/tokens. Each actual host spawn gets a unique SHM name and source epoch. Retained old mappings cannot collide with restarted hosts or publish into removed/replaced sources. Held-token refresh preserves CPU bytes and observation/frame identity. Original CPU/ISO representation and preparation-off behavior remain available; defaults remain off.
Actual opt-in WebView2/SHM pixels matched an independent CPU-upload compositor, with zero Program uploads/scratch uploads/texture creation. Host frames arrived before render polling; consumer recreation, blocked-reader polling and removal with a retained in-flight reader passed. The initial known-color test failed on WebView2's startup blank frame; that FAIL is retained and the corrected test waits for its independently specified page colors.
Real 1920x1080@60-requested browser trials, 1080p60 Program, isolation on and unchanged two-frame buffer: preparation on delivered 7,189 measured packets with zero buffer loss and one absorbed render overrun; control off delivered 7,192 with zero buffer loss and four absorbed overruns. Mean Program work was 0.363 ms prepared versus 2.841 ms control. Both sampled input/host progress checks passed, as did prepared-source GPU admission. Sampled selection age was median/p95 0 ms, max 47.9 ms; control has no comparable GPU source-identity age evidence. This is not per-frame host acquisition or capture-to-presentation latency qualification.
All 1,497 native tests pass on the frozen native tree; all 17 final-head CI checks on b684def pass (the build-tool installation stall was cancelled and its sanitizer job successfully retried). Native tree a5424be613f95f460c13b237bf750769b9f23431 is unchanged by rebasing onto merged #815; original trial commit c93cf51 is preserved locally. No installed beta, default change, receiver/display/A/V/fleet qualification or parent closure is included. NDI/SRT/RTMP CPU preparation, device recovery and #517 qualification remain open.