4 ms·

well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. ht

well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1 )

vanderZwan 9y ago
Of course, but I'm basically asking which of the two possible fallbacks would be better: - test for presence of WASM, if absent fetch the pre-compiled asm.js fallback - test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js. There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times. The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy: 1. On the main thread, the client kicks off a load of a URL by calling loadWebAssembly and receives a Promise<Function>. 2. The polyfill library starts up a worker containing asm.js code compiled from unpack.cpp concatenated with the glue code in load-wasm-worker.js. 3. The worker glue code fetches the binary via XHR then copies the result into the asm.js heap. 4. The asm.js code decodes the binary into asm.js in the form of UTF8 bytes in a separate region of the asm.js heap. 5. The worker glue code creates a Blob (a read-only copy) from a view of just the asm.js UTF8 bytes. 6. The Blob is postMessage()ed back to the main thread (a non-copying operation) where it is loaded as a script element with script.src = URL.getObjectURL(blob). 7. When the asm.js script is executed, it passes the asm.js module function object to a callback which resolves the promise in step 1.

vanderZwan 9y ago

Of course, but I'm basically asking which of the two possible fallbacks would be better: - test for presence of WASM, if absent fetch the pre-compiled asm.js fallback - test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js. There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times. The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy: 1. On the main thread, the client kicks off a load of a URL by calling loadWebAssembly and receives a Promise<Function>. 2. The polyfill library starts up a worker containing asm.js code compiled from unpack.cpp concatenated with the glue code in load-wasm-worker.js. 3. The worker glue code fetches the binary via XHR then copies the result into the asm.js heap. 4. The asm.js code decodes the binary into asm.js in the form of UTF8 bytes in a separate region of the asm.js heap. 5. The worker glue code creates a Blob (a read-only copy) from a view of just the asm.js UTF8 bytes. 6. The Blob is postMessage()ed back to the main thread (a non-copying operation) where it is loaded as a script element with script.src = URL.getObjectURL(blob). 7. When the asm.js script is executed, it passes the asm.js module function object to a callback which resolves the promise in step 1.