SharpMuPDF/mupdf/thirdparty/zxing-cpp/wrappers/wasm

WebAssembly/WASM Wrapper

Build

1. Install Emscripten if not done already.
2. In an empty build folder, invoke emcmake cmake <path to zxing-cpp.git/wrappers/wasm>.
3. Invoke cmake --build . to create zxing.js and zxing.wasm (and _reader/_writer versions).
4. To see how to include these into a working HTML page, have a look at the reader, writer and cam reader demos.
5. To quickly test your build, copy those demo files into your build directory and run e.g. emrun --serve_after_close demo_reader.html.

You can also download the latest build output from the continuous integration system from the Actions tab. Look for 'wasm-artifacts'. Also check out the live demos.

Alternative Wrapper Project

There is an alternative (external) wrapper project called zxing-wasm. It is written in TypeScript, has a more feature complete interface closer to the C++ API, spares you from dealing with WASM intricacies and is provided as a fully fledged ES module on npmjs.

Performance

It turns out that compiling the library with the -Os (MinSizeRel) flag causes a noticible performance penalty. Here are some measurements from the demo_cam_reader (performed on Chromium 109 running on a Core i9-9980HK):

| | -Os | -Os -flto | -O3 | -O3 -flto | Build system | |---------|-------|-------------|--------|-------------|-| | size | 790kB | 950kb | 940kb | 1000kB | All | | runtime | 320ms | 30ms | 8ms | 8ms | C++17, emsdk 3.1.9 | | runtime | 13ms | 30ms | 8ms | 8ms | C++17, emsdk 3.1.31 | | runtime | 46ms | 46ms | 11ms | 11ms | C++20, emsdk 3.1.31 |

Conclusions:

• saving 15% of download size for the price of a 2x-4x slowdown seems like a hard sale (let alone the 40x one)...
• building in C++-20 mode brings position independent DataMatrix detection but costs 35% more time
• link time optimization (-flto) is not worth it and potentially even counter productive