Performance
The decoder runs on the same thread as the UI, so the only number that matters is how long a frame takes. Everything below measures that in this browser, on this device, right now.
Decoder benchmark
Decodes generated symbols in a loop with no camera involved, so the result isolates the managed pipeline from capture and compositing.
Run the benchmark to time six symbologies and an empty frame on this device.
Live camera cost
The same pipeline on real camera frames, with duplicate suppression off so every decoded frame counts. Turn the knobs and watch the stage split move.
Ready
Frame diagnostics
Frame
0.00 ms
Headroom
0 fps
Decoded size
0×0
Scan lines
0
Grayscale 0.00 ms
Binarise 0.00 ms
Matrix 0.00 ms
Linear 0.00 ms
Knobs
What costs what
| Setting | Effect | When to change it |
|---|---|---|
| MaxProcessingSize | Quadratic. The dominant control. | Lower until the smallest symbol you care about stops decoding, then go one step back. |
| Formats | Linear in the number of decoders that run. | Always. Most applications need one or two symbologies. |
| Region | Proportional to the area kept. | Whenever the interface asks the user to aim. |
| MaxScanLines | Linear, and only for linear symbologies. | Lower for aimed scanning, raise for hands-off scanning. |
| TryHarder | Roughly triples matrix detection cost. | Still images only; it is off for live frames by design. |
| AllowInverted | Doubles the cost of frames that find nothing. | Only when white-on-black symbols are expected. |
| DownsampleFactor | Quadratic, applied inside the grayscale pass. | When frames arrive larger than you asked for and you cannot change the source. |