| name | flutter_scene-performance |
| version | 2 |
| description | Make a flutter_scene app hit frame budget. Use whenever a scene janks, stutters, or drops frames, or when the ask is to make it faster or run on mobile or web, because code-driven scenes are reliably slow and the fix depends on which thread is over budget, not on a guessed poly count. |
Making flutter_scene fast
A code-driven flutter_scene scene is reliably slow, and the usual reason is that nothing told you the budget or what to fix first, so optimization starts as guesswork. Guessing wastes iterations and often makes the wrong thread slower. This skill replaces the guessing with a budget, a way to measure it, and a fixed order to apply fixes in.
The one thing to internalize: measure the actual frame, find which of the two threads is over budget, then fix that thread. Do not target a triangle or draw-call number from memory. There is no built-in poly budget, and the same scene can be fast on desktop and jank on a phone. The number that matters is milliseconds per frame on the real target.
The budget
A frame has a fixed wall-clock budget set by the refresh rate.
- 60 fps is 16.6 ms per frame. 120 fps is 8.3 ms. Miss it and the frame janks.
- That budget is split across two threads, and either one blowing it drops the frame:
- UI thread runs your Dart. flutter_scene walks the scene graph, culls, updates components, and builds the render here.
- Raster thread is where Impeller draws the built frame on the GPU. The whole post-processing stack (ambient occlusion, reflections, depth of field, god rays, bloom) lands here.
- Mobile and web are the real constraint. Desktop GPUs hide a lot; a scene that runs smooth on a laptop can miss budget badly on a phone or in a browser. Profile on the lowest target you must support.
