Investigate moving editor code from Wasm to native in Tauri builds #2538

Rendering is where the heavy lifting occurs and that's what runs natively in the current Graphite integration of Tauri. The editor business logic is less performance sensitive (and any encountered slowness should be considered a bug) so for integration simplicity and cleanliness, we're initially keeping that running within Wasm.

It is also possible that this is the best engineering solution and we do want to stick with it. The web <-> native boundary has some IPC/websocket latency and the editor code directly processes user interactions with the UI. To keep it feeling as snappy as it does on web (which achieves a responsiveness that feels like a native app, not most web apps), it might be best to keep in Wasm if latency has a larger impact than processing speed.

A prototype should be made for this, and then the click-to-photon latency should be measured to compare actual responsiveness in both scenarios, under an array of workloads. If typical cases involve prolonged processing times for being non-native such that the final UI updates appear at a later time than they would under the prolonged latency scenario of running the editor code natively, then we pick the most responsive option accordingly. Special care should be taken for the most latency sensitive activities like painting, where results need to show up on screen with the least delay possible. There are special APIs both on web and (I believe) native for reducing some of that delay that may or may not be applicable/useful.

Rendering (graph execution) is and will remain native, which provides the performance gain that is of most significance. This issue merely describes a potential minor optimization to explore further at a later point in time.