@danbri @ErikSombroek @LinguaBrowse ahh, sorry; I getcha now.
I was probably referring to this (and other similar methods in debugDraw):
github.com/Birch-san/liqu…
in hot paths: I avoid Emscripten wrapPointer() (which allocates JS objects), and avoid property accesses (which I assume invoke wasm functions; not sure)
I was probably referring to this (and other similar methods in debugDraw):
github.com/Birch-san/liqu…
in hot paths: I avoid Emscripten wrapPointer() (which allocates JS objects), and avoid property accesses (which I assume invoke wasm functions; not sure)
@danbri @ErikSombroek @LinguaBrowse so, yeah: easily cut out. the idiomatic wrapPointer() is commented-out above. you'd use that, and lookup vert1.x and vert1.y, instead of using HEAPF32[vert1_p >> 2] and HEAPF32[vert1_p + 4 >> 2]
this is why liquidfun.js provided an "offsets" file:
github.com/google/liquidf…
this is why liquidfun.js provided an "offsets" file:
github.com/google/liquidf…
@danbri @ErikSombroek @LinguaBrowse to be clear: I'm *much* more worried by the Emscripten wrapPointer() than the prospect of a JS->wasm call. wrapPointer() causes an object allocation, which leads to either a JS memory leak (if kept forever) or garbage to be collected. can't sustain 60fps with GC pauses.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
