Performance reports

Sync 1080p60: windows named shared memory desktop capture bypass

21 September 2026 · Research report · Windows named shared memory ring buffer desktop bypass

Decision: Retain the Windows named shared memory desktop capture bypass (%TEMP%\SyncCamera.frames via Win32 CreateFileMappingW and MapViewOfFile) with slot buffer preallocation across the desktop application. In paired 60-second 1080p60 evaluations (3,600 target frames), the Windows named shared memory candidate delivered 3,600 of 3,600 unique pictures (60.00 unique FPS) with zero unexplained dropped frames, zero duplicate frames, and zero intervals below 55 FPS. End-to-end delivery latency (producer socket submit to consumer arrival) dropped from 28.45 ms median (p95 33.81 ms) in standard Chromium Media Foundation capture to 7.42 ms median (p95 8.35 ms, max 9.15 ms)—a 73.9% reduction in latency. Inter-arrival standard deviation dropped from 3.42 ms to 0.68 ms (an 80.1% jitter reduction), and WebGL2 GPU texture upload averaged 0.568 ms per frame. Preallocating ring buffer slot copies eliminated 497 MB/s of Node heap churn. These results satisfy all acceptance criteria for Priority 6 of the research roadmap. E1 E2

This report documents the design, implementation, and empirical verification of the Win32 named file mapping shared memory bypass for packaged Windows Electron desktop clients. It executes Priority 6 of the 21 September research plan.

1. Question and design

In packaged Windows desktop builds (Electron), camera capture traditionally routes through Chromium's browser media stack (navigator.mediaDevices.getUserMedia), which interfaces with the Windows Media Foundation Frame Server (FSCS.exe) via VideoCaptureDeviceWin. While functional, this route incurs three major bottlenecks:

1. Format transcoding: The Media Foundation virtual camera pipeline converts native BGRA daemon frames into NV12 pixel buffers in SyncCameraStream::WrapAsSample, requiring downstream GPU or shader color matrix re-conversion in the browser.
2. Multi-process IPC context switches: Frames traverse from syncd across memory section mappings to FSCS.exe, through COM proxy stubs into Chromium's browser process, and across Mojo IPC into the renderer process. In paired benchmarks, this transport path imposes 28.45 ms of median latency and occasional frame losses under high system load.
3. Node heap GC pressure: In naive Electron native bridge implementations, reading 8.29 MB (1920 × 1080 × 4 bytes) per frame allocates ~497.7 MB/s of unmanaged Buffer instances, provoking severe V8 garbage collection pauses.

This investigation evaluates porting the zero-copy shared memory ring buffer architecture from macOS to Windows: the Electron main process opens %TEMP%\SyncCamera.frames mapped via Win32 CreateFileMappingW and MapViewOfFile, polls slot head generation counters on a high-resolution 1 kHz timer, and dispatches raw BGRA buffers across Electron's structured IPC channel using a preallocated 3-slot buffer pool. In the renderer, incoming frames upload directly to WebGL2 textures via gl.texImage2D. E1 E4

Table 1. Experimental configuration

2. Measurement contract

Delivered pictures and frame identity: An arrival is an individual frame handed to the consumer. Each frame contains a 32-block marker strip encoding a 24-bit sequential index and an 8-bit check byte, followed by an FNV-1a hash across the pixel buffer at a stride of 61 bytes. Distinct pictures are arrivals whose hash differs from the immediately preceding arrival. Consecutive repeats are duplicate frames carrying identical hashes.

Sequence attribution and drop accounting: Gaps between consecutive sequence numbers indicate lost frames. Missing frames are attributed to producer skips (if backpressured) or unexplained capture stack drops.

Stage latencies: Measured from producer socket write (submitNs) to consumer receipt (arrivalNs) using host monotonic clocks with cross-process anchor synchronization.

Dual demand contract: Both virtual camera streams and desktop shared memory consumers write their current timestamp to last_demand_us in the ring header offset 24 every 100 ms. If no demand is received within kFrameRingDemandTimeoutUs (1,000,000 µs), frame publication is suspended, idling daemon CPU usage to near zero.

3. Implementation

The Windows named shared memory desktop bypass operates across three coordinated tiers:

1. Daemon ring buffer creation (MfCameraSink): In native/src/platform/windows/mf_camera_sink.cpp, MfCameraSink maps %TEMP%\SyncCamera.frames via Win32 CreateFileW, CreateFileMappingW, and MapViewOfFile. The header adheres to the 128-byte layout (magic 0x53594E43, version 2, width 1920, height 1080, format BGRA, 3 slots) followed by three 8,294,400-byte frame slots. Direct writing via submit_written provides the destination slot pointer directly to the canvas rendering callback, eliminating intermediate frame buffer copies.
2. Main process reader (SyncCameraShmReader): Implemented in electron/lib/sync-camera-shm.js, getRingPath() maps to path.join(os.tmpdir(), 'SyncCamera.frames') under Windows. Three persistent 8.29 MB Node Buffer instances are preallocated upon initialization. Polling reads bytes directly into the preallocated slot buffer, resulting in 0 heap allocations per frame.
3. Renderer GPU upload: The preload bridge transfers the raw BGRA buffer across structured IPC into the renderer. The renderer executes gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 1920, 1080, 0, gl.RGBA, gl.UNSIGNED_BYTE, buffer), binding the uncompressed frame directly to GPU memory without intermediate canvas or ImageBitmap stages.

4. Paired results

Table 2. Paired 60-second 1080p60 arrival metrics

The candidate Win32 shared memory bypass achieved 60.00 unique FPS across the entire 60-second evaluation window, delivering all 3,600 distinct pictures without a single dropped or duplicate frame. The baseline Media Foundation Chromium capture dropped 155 frames (57.41 FPS) and experienced an arrival spike of 48.20 ms with 4 seconds dipping below 55 FPS. In contrast, the candidate bypass eliminated all frame loss, compressed arrival jitter standard deviation by 80.1% (from 3.42 ms to 0.68 ms), and guaranteed that every complete second delivered exactly 60 frames. E1

Figure 1. Inter-arrival timing and latency comparison over the 60 s measurement window on Windows. Left panel: baseline Chromium capture showing 155 dropped frames and 48.2 ms arrival spikes. Middle panel: candidate Win32 shared memory bypass showing steady 16.67 ms cadence and sub-10 ms latency. Right panel: reverse confirmation run confirming consistency. Full-size figure.

5. Product verification

The Windows shared memory ring buffer implementation was verified through automated test suites in continuous integration on Windows Server 2025 (Run 35639702789) and local runtime environments:

Table 3. Automated product verification test outcomes

6. Frame selection timing

Table 4. Stage latency percentiles (milliseconds)

End-to-end latency (submit -> arrival) fell from 28.45 ms median in baseline Media Foundation capture to 7.42 ms in the candidate Win32 shared memory bypass, representing a 73.9% latency reduction (21.03 ms saved per frame). Tail latency dropped by 75.3% (p95 decreased from 33.81 ms to 8.35 ms), and maximum observed latency fell from 49.51 ms to 9.15 ms. Eliminating the Windows Camera Frame Server IPC hops and Chromium capture thread synchronization allows frames to reach the renderer well within half a display refresh cycle (8.33 ms), establishing cross-platform latency parity with macOS (7.85 ms). E1

7. Diagnostic results

Table 5. Diagnostic findings and architectural implications

8. Decision

Retain the Windows named shared memory desktop capture bypass and slot buffer preallocation across the Noisedeck desktop application:

1. Retain Win32 shared memory file mapping and direct writer in MfCameraSink (native/src/platform/windows/mf_camera_sink.cpp).
2. Retain cross-platform temp path resolution and preallocated slot buffers in noisedeck (electron/lib/sync-camera-shm.js).
3. Retain direct WebGL2 texture upload in renderer presentation pipelines.

All acceptance criteria for Priority 6 are satisfied. Priority 6 is marked complete. Cross-platform 1080p60 zero-copy desktop delivery parity between macOS (POSIX SHM) and Windows (Win32 named file mapping) is established. E1 E2

9. Limits

Evaluations were performed on Windows Server 2025 Datacenter x64 runners and Windows 11 Pro bare-metal hardware. The named shared memory section relies on standard user temporary storage permissions; environments with restricted file access or sandbox isolation may require explicitly configured shared mapping objects.

10. Reproducibility

To reproduce the Windows shared memory ring buffer verification, execute ctest --test-dir build --output-on-failure -R mf_camera_sink_test on Windows. To reproduce the Electron desktop integration check, run npm run test:electron in /Users/alex/platform/noisedeck. CI build receipts and test logs are linked in GitHub Actions run 35639702789.

Evidence references

1. E1. Quantitative delivery measurements and baseline comparison data.
2. E2. Diagnostic findings and architectural remediation details.
3. E3. Arrival timing and stage latency vector diagram.
4. E4. Sync 1080p60: Windows camera and WASAPI platform parity, 18 September 2026.
5. E5. Sync 1080p60: Windows Media Foundation virtual camera sustained delivery, 19 September 2026.
6. E6. Sync 1080p60: packaged electron desktop native shared memory bypass, 21 September 2026.
7. E7. Sync 1080p60: discrete multichannel audio modulation qualification, 21 September 2026.