fix(studio): render frames on a stack deep enough to deserialise them - #210
Merged
Conversation
Opening a deeply nested scenario aborted the whole process with a stack overflow, while the same file rendered fine from the CLI. The depth cost is deserialisation, not painting: `prepare_scene` calls `deserialize_children` on every frame, and `ChildComponent` -> `Component` -> `Container`/`Card` recurses once per level. Those enums are untagged, so serde buffers each level through `ContentDeserializer` — a level is expensive in stack as well as deep, and a debug build's frames are several times fatter. Measured on a 28-level scenario: between 2 and 4 MiB needed in debug. Rust gives a spawned thread 2 MiB, so the prefetch workers overflowed; the CLI survived only because it happens to render on the 8 MiB main thread. Both webview asset handlers were exposed for the same reason. All three render sites now get an explicit stack. `render_frame_deep` is scoped, so the scenario and tasks are borrowed rather than cloned. Adds a probe test that reports the stack a given scenario needs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happened
cargo run --bin rustmotion-studioaborted at startup on a deeply nestedscenario:
The same file rendered fine through
rustmotion render.Why
The crash report puts the recursion in deserialisation, not in the paint
walk.
prepare_scenecallsdeserialize_childrenon every frame, andChildComponent→Component→Container/Cardrecurses once per level ofnesting. Those enums are untagged, so serde buffers each level through
ContentDeserializer— every level costs stack as well as depth. A debugbuild's frames are several times fatter than a release build's, which is why
this only shows up under
cargo run.Measured with the probe test below, on a scenario nested 28 levels:
Rust gives a spawned thread 2 MiB. So:
webview-owned threads, no better off
28 levels is not pathological: a UI composed from small helper functions
(
shell→ body → content → col → row → badge) reaches it without trying.The fix
All three render sites get an explicit stack.
render_frame_deepis scoped,so the scenario and tasks are borrowed rather than cloned per call; the
prefetch workers are sized once at spawn rather than per frame.
Not fixed here
deserialize_childrenruns per frame. That is a real cost on every render andthe reason the stack is deep in the first place — caching the deserialised tree
would fix both, but it is a bigger change than a crash fix should carry.