Comment by flohofwoe
> - the incredible overhead of each and every API call
The calling overhead between WASM and JS is pretty much negligible since at least 2018:
https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
> - - the nerfed timers that jitter on purpose
At least Chrome and Firefox have "high-enough" resolution timers in cross-origin-isolated contexts:
https://developer.chrome.com/blog/cross-origin-isolated-hr-t...
...also, if you just need a non-jittery frame time, computing the average over multiple frames actually gives you a frame duration that's stable and exact (e.g. 16.667 or 8.333 milliseconds despite the low-resolution inputs).
Also, surpise: there are no non-jittery time sources on native platforms either (for measuring frame duration at least) - you also need to run a noise-removal filter over the measured frame duration in native games. Even the 'exact' presentation timestamps from DXGI or MTLDrawable have very significant (up to millisecond) jitter.
> - the limitation of a single rendering context and that you must use the JS main thread to all those rendering calls (so no background async for you..)
OffscreenCanvas allows to perform rendering in a worker thread: https://web.dev/articles/offscreen-canvas
I didn't mean just WASM -> JS but the WebGL API call overhead which includes marshalling the call from WASM runtime across multiple layers and processes inside the browser.
Win32 performance counter has native resolution < 1us
OffScreencanvas is something I haven't actually come across before. Looks interesting, but I already expect that the API is either brain damaged or intentionally nerfed for security reasons (or both). Anyway I'll look into it so thanks for that!