Direct RGBA receive: allocation pooling, round two
Configuration and method
The host uses an Apple M2, 8 logical CPUs, 24 GiB of memory and Darwin 23.6.0.
These hardware values come from retained host metadata, not from an in-run sample.
Timing runs use synth.testPattern with pattern 0 and gridSize 4.
Positive and negative controls use pattern 5 and gridSize 16.
The compiled state and shader uniforms match these values before and after each run.
Both configurations use GLSL and write to output o0.
These task-local research fixtures send 1920 × 1080 RGBA packets from Noisedeck A to Noisedeck B.
Native camera publication remains active. B receives direct RGBA over HTTP with a BYOB reader, not through the camera.
BYOB means that the reader supplies a buffer for incoming bytes.
The receiver pooling arm reuses its cleanup notification state and reads image size through the public getter.
The uploader arm also reuses storage for saved GL state and errors. It still queries current GL state before each upload.
The ACK and source-encoder arms extend the uploader independently.
The ACK arm retains the acknowledgement header writer and its fixed generation.
The source-encoder arm retains fixed frame-encoding views and uses a stable completion callback.
The source-encoder arm does not include the ACK pooling change.
The native-message arm uses the original BYOB browser and a different native executable.
The Message-vector pool retains empty message slots. The existing decoder still reuses its non-sensitive payload buffer.
Each row describes one complete run. Each run has 180 complete seconds and a separate final partial interval.
The late BYOB web reference repeat appears separately. It does not replace the earlier baseline.
Unique pair rates use the full elapsed duration. The observer checks input markers against markers from the same render.
Each arm has same-context positive and poison-negative controls with full pixel comparisons.
The new arms use fresh controls.
The late BYOB reference reuses and revalidates the exact original web controls. It has no new pixel controls or five-second qualification.
Measurement results
Web: final unique counts for each complete second. The partial interval appears only in the table. Open the full-size web chart.
Desktop: final unique counts for each complete second. The partial interval appears only in the table. Open the full-size desktop chart.The tables retain input and final counts separately. The plots show every complete second without smoothing.
Each plot uses its own B page clock. The plots do not align separate runs in wall time.
The table describes individual runs. It does not estimate the effect of each code change.
Failed attempts
BYOB receiver · web · web-observe180-byobv1-a1.
The source renderer stopped during the run. The cause remains unresolved.
The recorded failure stage is measurement. Overall cleanup complete is false.
Receiver pooling · desktop · desktop-observe180-poolv1-a1.
The controller received the wrong negative-control path. It rejected the attempt before measurement.
The recorded failure stage is host-power. Overall cleanup complete is true.
Limitations
The runs occurred sequentially. They do not establish a causal ranking or repeatability.
These three-minute observations do not establish sustained 60 frames/s.
These results do not establish performance of the released product, external camera delivery or hours-long operation.
The tests do not isolate garbage collection as the cause of any frame gap.
Marker observation adds diagnostic work. Its allocation costs differ from those of the product renderer.
Separate renderer and pressure diagnostic drafts are not part of these throughput comparisons.
Power checks sample AC status at controller cuts. They do not provide continuous power measurements.
Native stage totals include setup and cleanup. They use a separate monotonic clock and do not share the B measurement interval.
Native slow-event retention can overwrite earlier events. The table retains the actual loss count.
Source references
Hardware and source configuration proofs · Metrics and source digests · Report text · Checksums
The metrics include result, control, source-manifest, journal and native-receipt digests.
SHA256SUMS identifies every public file. The report does not include the private receipts.