I expected the Rust port to feel lighter and faster than Electron. Instead, switching shots or acts made the screen jump and brought repeated little loading states. If the app is slow enough to interrupt production, a language's theoretical speed does not help me. I am moving the production workflow back to Electron.
This is not a conclusion that Rust cannot produce a fast interface. Tracing this implementation points to a narrower cause: what gets reopened, copied, and handed to the screen during a context switch matters more than the language label.
A / TWO INTERACTION PATHS
The same click did not do the same work
In Electron, the React workspace keeps the selected project resident. Node selection waits for the navigation flush, updates the selected ID, and expands the necessary ancestors. The view renders from the project already held in the workspace.
In the Rust path, the host marks the view busy when it receives SelectNode, then sends the request to a session worker. `prepare_context_switch` rereads the store, validates the project revision and target context, and creates a candidate session. `session_payload` clones its full snapshot and copies each board’s selected media bytes into new vectors. The host then invalidates related Boards, Review, Generation, and Timeline state and rebuilds the board list. When an exact clean image cannot be reused, it decodes the image, sends a new RGBA frame to egui, and registers a GPU texture. Timeline adds another composition-preparation and native-playback step before its preview appears. Revision checks and protection for in-progress edits have a purpose, but this port puts that work back on the shot-switch interaction path.
C / THE SCREEN RECORDINGS
What the transition looked like
Both recordings show the same 5RPS project, but they start with different board counts and do not capture the same action sequence. In the Rust recording, the Timeline preview shows “Composition preview unavailable” while the app says “Please wait for the current operation.” The image appears later. In the Electron recording, a composition image is visible after entering Timeline. That is the difference visible in these recordings, not a matched speed test.
Electron screen recording
Rust screen recording
The source captures are 4K. The web copies keep their aspect ratio at 1920×1204 and use H.264/AAC at 48 fps. The original files remain untouched.
B / WHAT THE COMMITS RECORD
The loading handoff kept needing repair
The migration commits show repeated work on the handoff itself. For example, `c065c575` reads “Fix Rust context navigation stalls and loading layout shifts”; `360f9179`, “Keep context navigation steady and enable live timeline scrubbing”; `0b40fe26`, “Keep every context page steady while its replacement loads”; and `57a5fc2c`, “Keep timeline context steady until preview is ready.” Keeping the old view visible during loading softens a jump, but it does not remove the work needed to prepare the next context.
`f25daf73`, “defer unused rasters,” was another local improvement: postpone images that were not needed. Those fixes mattered, but they did not prove that selection had become cheaper than in Electron.
The recordings support the visible wait-state observation, and source inspection explains work that can prolong it. The projects start with 15 and 22 board pages respectively, and the actions differ. I do not have frame-timed captures of the same project state and interaction sequence, so their clip lengths are not a speed ratio.
D / THE DECISION
I am stopping this port, not declaring Rust impossible
Rust is a strong choice for CPU work, memory control, and native integration. But UI responsiveness is not determined by language alone. I/O waits, image decoding, unnecessary clones, synchronous preparation, render invalidations, and loading-state transitions can make Rust feel slow and uneven. Electron is not magically fast; in this implementation it can change selection inside a project that is already open. For this workflow, that architectural difference mattered.
To keep production moving, I am using the Electron app. I have prepared a timeline-ruler change that coalesces pointer positions to animation frames and always applies the final pointer position on release. I will QA this updated package by hand. This change does not claim to resolve the slow context switches or screen jumps.
If I revisit Rust, I need to change the architecture first: reuse context snapshots, load only visible board images, share media or texture caches, and prepare Timeline asynchronously, then measure both apps under identical conditions. For now, I am choosing to return to the tool I can use.
Source references: Electron workspace selection, Rust session payload, Rust Timeline preparation.