screenferry — test app

1. Self-test (no camera needed)

Sends a file to a hidden canvas and reads it straight back via a captured canvas stream — same trick as loopback-demo.html. Runs the real encodeToFrames → DisplayDriver → NegotiatingReceiverSession pipeline end to end, in this browser, without needing a second device or a real camera. This is the fastest way to check whether the selected backend actually works here at all.

Run self-test

idle

Download reconstructed file

2. Send (real screen, for a second device to scan)

Requires a real camera on the receiving end (section 3, on this device or another one). If the receiver is a different device on your network, plain http://<lan-ip> won't get camera access — browsers require a secure context (https://, or localhost on the same device) for getUserMedia. See the README's Browser support section.

Start Stop

The canvas below displays at its native resolution (drag its bottom-right corner to resize further). Avoid shrinking it — a downscaled code is harder for the receiving camera to resolve; hold the camera closer instead if you want the code to fill more of its view.

idle

3. Receive (real camera)

Point this device's camera at another device running section 2. Drag the video's bottom-right corner to resize the preview — a bigger preview makes it much easier to judge whether the code fills the frame cleanly (see the tuning notes below).

Start scanning Stop

idle

Download reconstructed file

Speed tuning notes (qr-lt)

qr-lt's throughput is roughly fps × fragmentSize bytes/second, bounded by how fast the receiver can actually scan and decode. Two knobs, both above:

• fps — DisplayDriver's display rate. Higher sends more frames/second, but the receiver's camera and decode loop need to keep up, or frames just get skipped without being scanned (no benefit, same failure mode as raising it too far).
• fragmentSize — bytes packed into each QR frame. Bigger means fewer total frames needed, but a denser, harder-to-scan QR code — reliability drops if the receiver's camera can't resolve it clearly (resolution, distance, focus, motion blur all matter more as this grows). Leave blank for the library's own tuned default (~2111 bytes, chosen for reliable scanning at ECC level L / QR version ≤ 40 — see qr:capacity in package.json if you want to compute a different ceiling).
• scanHz — how often the receiver samples a camera frame for decoding. Should track roughly 2× the sender's fps (the default) — much lower and it may miss frames as they change; much higher just burns CPU decoding the same still-displayed frame repeatedly, with no throughput benefit.
• decode workers — how many camera frames the receiver can decode in parallel. Defaults to 1 (this library's original behavior): a single zxing-wasm decoder serialized behind every captured frame, so raising scanHz past that one decoder's own throughput bought nothing. Raising this past 1 lets that many frames decode concurrently — worthwhile on capable hardware, especially alongside a higher scanHz, since decode latency was the de facto ceiling on how much of it was actually usable. Each worker costs its own ~1MB zxing-wasm instance plus a startup delay, and on a low-end phone several concurrent decodes can thrash the CPU rather than help — there's no universally safe value above 1, so this is left as a manual, per-device choice rather than an automatic default. The goodput reading next to the progress bar above is the way to tell whether a given value actually helped on your device.

Beyond these knobs: QR ECC is already at the library's minimum overhead level (L), so there's no further redundancy to trade away. On the physical/environmental side — screen brightness/contrast, camera autofocus lock, holding distance/angle steady, and reducing motion blur — all matter more than they might seem, and are usually a bigger lever on real-world reliability (which is what lets you safely raise fps/fragmentSize in the first place) than any of the code-level knobs above.