np-eazy
commented
1 year ago Based on how it is playing out, the render-to-update ratio seems low enough that everything can be kept in JavaScript; everything is either a debug message or a rectangle, and any significant Rust improvements on the update calls will probably mean rewriting the whole codebase. Still leaving this open in case someone wants to take it all the way with rust/wasm rendering.
If we are going in that direction, then the JS/Rust interface can get kinda interesting; what I'm thinking is that each JS-end "Cell" can be mapped via UUID to a Rust-end "Cell" and the JS update() asynchronously drives render-update loops in the Rust end; enforcing downstream dependency with as little coupling as possible.
For each JS Cell, Rust has another layer of structed props to use for rendering, and is updating those props without involving any JS code.
- Cells get idle, active, advance update calls from the JS side, changing their JS props
- Rust receives a call to update a Cell with a certain UUID; if it doesn't have that it generates a default, otherwise get a free worker thread to update the Cell's Rust data
- The worker thread then renders the cell
With Rust threads there would be a lot of room for parallelization especially since most times cells do not overlap and there will be no race conditions. However, some synchronous calls should still be enforced to make sure that falling pieces, targets, and the cursor are in a consistent z-ordering.
See comment below