Hacker News Reader

Comment by blixt | Hacker News Reader

Cool!

One question – you are moving a lot in and out of the JavaScript and Rust "worlds" in your render function. Have you measured the difference of just creating a simple data structure with the render instructions and passing that once to JavaScript instead? I would expect that to be much faster.

View on HN

The interface between WASM and JS is limited to native types that WASM supports which is just integers [0] (and maybe doubles?). With that limited API you cannot pass full structures around, the best you can do is pass what are essentially pointers to memory around [1].

[0] - https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

[1] - https://becominghuman.ai/passing-and-returning-webassembly-a...

You can do something very similar in plain JS using a sharedArrayBuffer and a webworker. A sharedArrayBuffer is a typed array in an area of shared memory that the worker and the main script can both access. It works really well if it fits your use case. I wrote a 'javascript snow' thing that uses it - https://github.com/onion2k/snowfall

Doubles are supported as well through the `f64` type I think. Interestingly, I am passing booleans in my code as well... and it seems to work.

I wonder if its converting them to 0's and 1's and sending that to the javascript?

Just checked what is going on and that is indeed the case. Rust booleans compile now to the i32 type (though there is no guarantee that will stay like that in the future).

I haven't measured anything :P

Regarding your suggestion, I cannot pass an object to Javascript, because from the perspective of the browser I am writing C. An alternative would be to have each function take a pointer to the object, but it is quite cumbersome and I doubt it would have any (positive) impact on performance.

I was thinking you can create a byte buffer of fixed size instructions that you can pass from Rust to JavaScript. With for example DataView you can fairly easily inspect that data in JavaScript.

Or to keep things even simpler, if every class of draw instructions is always performed in order (so not drawEnemy, drawText, then another drawEnemy) you could just have separate arrays of arguments for every draw type.

Anyway for your game specifically I doubt this is even close to an issue, but I'm curious just how performance scales when you jump in and out of JS a lot in WASM.

Never heard of DataView before, thanks! This is the first time I do something "low level" in Javascript, so there is probably a lot that could be improved.

BTW, here is an example passing arrays between Javascript and Rust: https://www.hellorust.com/demos/canvas/index.html

so you can only pass simple types and nothing like a framebuffer array ? great work btw!

Since WASM in its current state is meant as a compilation target for C, it is usually possible to do things "the C way". For instance, you can allocate a buffer on the Javascript side and pass a pointer to the Rust side, which then can write to it. You can also allocate it on the Rust side and return it. This is for instance what you do when you want to return a string.

Reply on news.ycombinator.com