Restructure JS <-> Wasm communication flow and adopt parallelism

[Keavon]

Right now, JS calls into Wasm, then that calls back into JS again, and that might call back into Wasm, and so on. It does that within the same call stack, so the call stack gets deeper and deeper ping-ponging between the two languages.

We want to flatten this out and build a queue system so either side can queue up tasks. One side processes its queue while building up a queue for the other side, then when done, it switches to the other side and works through its queue on that side, building up tasks for the other side to complete, then it switches again when the queue is done.

We also want to utilize web workers wherever possible to get everything but the DOM manipulations off the main thread, and also benefit where possible from parallelism.

[0HyperCube]

The backend rust code already queues up a list of FrontendMessages. With the javascript, it is not clear how to queue up a list of messages.

[TrueDoctor]

I guess we could just queue them up in the wasm wrapper and send them to the backend running in a separate thread using a channel.

On 23/04/14 12:14, 0HyperCube wrote:

The backend rust code already queues up a list of FrontendMessages. With the javascript, it is not clear how to queue up a list of messages.

-- Reply to this email directly or view it on GitHub: https://github.com/GraphiteEditor/Graphite/issues/1113#issuecomment-1508038992 You are receiving this because you were assigned.

Message ID: @.***>

[TrueDoctor]

I think the first part of this issue is basically implemented. The only thing left to do is to actually use multi threading on the web