Reduce initial WASM memory and auto-grow it#122
Conversation
hb_sets are always u32s, so there's no need for this to try and support anything else (this is prep work for making the wasm memory resizeable)
|
Thanks! |
|
Does |
If I do so, I get the following when trying to run |
|
@khaledhosny oh, that’s the same error I ran into with the regular It seems like harfbuzzjs 4.x is broken in Node.js |
It does not generate a wrapper file currently so we would need to do that first. I see that the README shows fetching .wasm and instantiating manually, but some emscripten features like the one this PR added rely on the wrapper file. I think we should only support loading it through the wrapper, like the tests and examples do.
To be clear, |
Please submit a PR that updates the README file. I think I attempted to do that once, but I don’t remember why I didn’t. |
Trying to. That example uses To get the simple index.js import working in Vite and Bun, probably the first step is to convert everything to use ESM, which the JS world has mostly moved to anyways. |
ESM would be nice 👍 |
Emscripten updates the views it exposes (
Module.HEAPU8etc) whenever memory resizes so, compiler flags aside, all this does is remove aliasing. We can still have aliases, but they have to be re-created after any calls that could have resized memory. It's easier and safer to just write the whole thing out, and JS engines are really good at inline caching anyways.Fixes #117