Mercurial > hgrepos > Python2 > PyMuPDF
diff 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 |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/mupdf-source/thirdparty/zxing-cpp/wrappers/wasm/README.md Mon Sep 15 11:43:07 2025 +0200 @@ -0,0 +1,32 @@ +# WebAssembly/WASM Wrapper + +## Build + +1. [Install Emscripten](https://kripken.github.io/emscripten-site/docs/getting_started/) 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](demo_reader.html), [writer](demo_writer.html) and [cam reader](demo_cam_reader.html) 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](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). + +## Alternative Wrapper Project + +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). + +## 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 +
