WASM output added to Emscripten build process

[raxhvl]

-s WASM=1 — Specifies that we want wasm output. If we don’t specify this, Emscripten will just output asm.js, as it does by default.

The WASM build will provide significant performance improvement for the dependent JavaScript library: libheif-js

[farindk]

Why did you close this? Is there any problem with WASM output? Did you compare the WASM speed with JS?

[raxhvl]

Why did you close this?

WASAM binary loads asynchronously, I need to figure out how to initialize the post.js code correctly during the build (I have manually moved post.js code to libheif-post.js script now). I also need a onRuntimeInitialized callback in the client script, so i know when the library has loaded. Let me know if you have any comments on this.

Is there any problem with WASM output

No

Did you compare the WASM speed with JS

Yes. WASM is faster. You can test it here: https://heif-wasm-ravindranrahul.vercel.app/
Source: https://github.com/ravindranrahul/heif-wasm

[farindk]

Thanks for the insight. I'm looking forward to having WASM support !

[raxhvl]

I have completed the refactoring of the JavaScript code; summary below:

1. pre.js and post.js was wrapping the entire library in an inner function. This is a bad practice. I have separated them.

In particular, --pre-js code should not alter the main output from emscripten in ways that could confuse the optimizer, such as using --pre-js + --post-js to put all the output in an inner function scope (see MODULARIZE for that)

Source: https://emscripten.org/docs/tools_reference/emcc.html#emcc-pre-js

2. Moved the code that exposes the C API to to libhef.load(). This needs to be called after the WASM binary has loaded asynchronously using Module.onRuntimeInitialized

window["Module"] = {
  onRuntimeInitialized: function () {
    libheif.load();
  },
};

3. Formatted the JS code. Let me know if its difficult to review after formatting. I can remove that.

[aminya]

Why is this PR closed?