Mercurial > hgrepos > Python2 > PyMuPDF
comparison mupdf-source/thirdparty/zxing-cpp/wrappers/wasm/README.md @ 2:b50eed0cc0ef upstream
ADD: MuPDF v1.26.7: the MuPDF source as downloaded by a default build of PyMuPDF 1.26.4.
The directory name has changed: no version number in the expanded directory now.
| author | Franz Glasner <fzglas.hg@dom66.de> |
|---|---|
| date | Mon, 15 Sep 2025 11:43:07 +0200 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| 1:1d09e1dec1d9 | 2:b50eed0cc0ef |
|---|---|
| 1 # WebAssembly/WASM Wrapper | |
| 2 | |
| 3 ## Build | |
| 4 | |
| 5 1. [Install Emscripten](https://kripken.github.io/emscripten-site/docs/getting_started/) if not done already. | |
| 6 2. In an empty build folder, invoke `emcmake cmake <path to zxing-cpp.git/wrappers/wasm>`. | |
| 7 3. Invoke `cmake --build .` to create `zxing.js` and `zxing.wasm` (and `_reader`/`_writer` versions). | |
| 8 4. To see how to include these into a working HTML page, have a look at the [reader](demo_reader.html), [writer](demo_writer.html) and [cam reader](demo_cam_reader.html) demos. | |
| 9 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`. | |
| 10 | |
| 11 You can also download the latest build output from the continuous integration system from the [Actions](https://github.com/zxing-cpp/zxing-cpp/actions) tab. Look for 'wasm-artifacts'. Also check out the [live demos](https://github.com/zxing-cpp/zxing-cpp#web-demos). | |
| 12 | |
| 13 ## Alternative Wrapper Project | |
| 14 | |
| 15 There is an alternative (external) wrapper project called [zxing-wasm](https://github.com/Sec-ant/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](https://www.npmjs.com/package/zxing-wasm). | |
| 16 | |
| 17 ## Performance | |
| 18 | |
| 19 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): | |
| 20 | |
| 21 | | `-Os` | `-Os -flto` | `-O3` | `-O3 -flto` | _Build system_ | | |
| 22 |---------|-------|-------------|--------|-------------|-| | |
| 23 | size | 790kB | 950kb | 940kb | 1000kB | _All_ | | |
| 24 | runtime | 320ms | 30ms | 8ms | 8ms | C++17, emsdk 3.1.9 | | |
| 25 | runtime | 13ms | 30ms | 8ms | 8ms | C++17, emsdk 3.1.31 | | |
| 26 | runtime | 46ms | 46ms | 11ms | 11ms | C++20, emsdk 3.1.31 | | |
| 27 | |
| 28 Conclusions: | |
| 29 * saving 15% of download size for the price of a 2x-4x slowdown seems like a hard sale (let alone the 40x one)... | |
| 30 * building in C++-20 mode brings position independent DataMatrix detection but costs 35% more time | |
| 31 * link time optimization (`-flto`) is not worth it and potentially even counter productive | |
| 32 |