- Install Emscripten if not done already.
- In an empty build folder, invoke
emcmake cmake <path to zxing-cpp.git/wrappers/wasm>. - Invoke
cmake --build .to createzxing.jsandzxing.wasm(and_reader/_writerversions). - To see how to include these into a working HTML page, have a look at the reader, writer and cam reader demos.
- 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.
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.
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