ceskacan.
TR

Browser architecture / QR Studio

Moving a camera frame to a Worker

Separating work also means identifying which request each response belongs to.

2 min read

Define the data boundary

The scanner converts a camera frame to pixel data. The Worker needs the frame buffer, width, height and request ID, rather than the entire interface state. A small, explicit message contract makes the responsibilities of both sides visible.

Inside the Worker

The Worker creates a Uint8ClampedArray from the received buffer and calls jsQR. Decoding returns data or an empty value. A caught error also produces a response carrying the same request ID, allowing the caller to distinguish a result from a handled error.

Why the request ID matters

The scanner module matches pending requests by ID. Returning that ID is consequently part of the workflow. Sending only the decoded text would not explain which pending operation it belongs to in an asynchronous flow. The ID connects the two sides.

Architecture and measurement

Running decoding in a dedicated Worker is a verified architectural choice. The FPS benefit is a separate measurement question. A useful measurement compares the same camera frame, device and decoder settings. The camera scanner Worker also has a different responsibility from the Worker used to verify generated QR payloads.

Open the source excerpt ↗