Re-implement callbacks in JS

[khaledhosny]

This paves the way to passing callback functions from JS to wasm and serves as an example.

[behdad]

Any perf numbers?

[khaledhosny]

There does not seem to be any measurable difference. Drawing the same glyph a million times:

old:

real    0m10.935s
user    0m10.871s
sys 0m0.242s

new:

real    0m10.954s
user    0m10.875s
sys 0m0.256s

Drawing all glyphs in NotoSans-Regular a 100 times:

old:

real    0m2.510s
user    0m2.509s
sys 0m0.073s

new:

real    0m2.522s
user    0m2.522s
sys 0m0.078s

[behdad]

That's quite impressive!

[chearon]

That's consistent with what I've found. I did a lot of profiling of C++ map, string, and array operations vs JS equivalents, and JS was at worst the same. String concatenation was always faster in JS. Though one thing nice about C++ is you don't have the garbage collector running, which can take seconds when you're working with huge amounts of memory.

This looks great! I did not know about Module.addFunction. I can make a PR for <canvas> support, it's not hard after this.

---

A little off-topic (shameless plug?) but I moved my harfbuzzjs efforts to here. One thing I did to get hbjs working in a production environment was put the glyph infos, positions and flags in a flattened Int32Array (so like an array of structs in C) instead of the JS objects this currently uses. That was key in getting good perf for shaping massive amounts of text. I also added OpenType functions used for font selection, and necessary feature/lookup functions for porting Firefox's glyph cache. Hopefully I can contribute that stuff back, but it was difficult to have WASM bundles for every dependency. TypeScript in particular would be really nice to have here.

[behdad]

Thanks for sharing. I don't think TypeScript is a problem.

[khaledhosny]

Any objection to merging this?

[behdad]

Go ahead!