When dragging a node graph frame around which now rasterizes every frame thanks to #1100, the JS is sending lots and lots of binary data to the Rust code. This also happens when repeatedly using Imaginate to generate many images (including the in-progress generation preview images) after enough generations (like 50 or more). It ends up using more memory than the wasm allocator can handle, since apparently we're not freeing the memory or something. It results in a freeze of the editor and spamming the console.
We run into this issue with wasm-bindgen where we use up the 2GB of memory and JS thinks the pointer is negative: wasm-bindgen/wasm-bindgen#2388. That was fixed six weeks ago in wasm-bindgen/wasm-bindgen#3310 but doesn't seem to have made it into a release yet. It doubles the available memory to 4GB which is the maximum until wasm memory64 becomes available. Once we can use the full 4GB, we should also add proper error handling to tell the user what has happened if memory has been all used up so it doesn't result in a mysterious ceasing to work.
Increasing that allocation limit would be important, but more importantly, we need to fix the cause of the problem which is that memory seems to not be freed, or at least not be available again for use by the allocator.
When dragging a node graph frame around which now rasterizes every frame thanks to #1100, the JS is sending lots and lots of binary data to the Rust code. This also happens when repeatedly using Imaginate to generate many images (including the in-progress generation preview images) after enough generations (like 50 or more). It ends up using more memory than the wasm allocator can handle, since apparently we're not freeing the memory or something. It results in a freeze of the editor and spamming the console.
We run into this issue with wasm-bindgen where we use up the 2GB of memory and JS thinks the pointer is negative: wasm-bindgen/wasm-bindgen#2388. That was fixed six weeks ago in wasm-bindgen/wasm-bindgen#3310 but doesn't seem to have made it into a release yet. It doubles the available memory to 4GB which is the maximum until wasm memory64 becomes available. Once we can use the full 4GB, we should also add proper error handling to tell the user what has happened if memory has been all used up so it doesn't result in a mysterious ceasing to work.
Increasing that allocation limit would be important, but more importantly, we need to fix the cause of the problem which is that memory seems to not be freed, or at least not be available again for use by the allocator.