setState coalescing prevents per-update frames during rapid UI changes

Direct answer

Flutter’s setState() does not promise one build per call. It marks the target State dirty and asks the scheduler for a frame. Calls that arrive in the same event-loop tick are normally coalesced into a single build pass for the next frame. This is intentional; Flutter cannot run more than one build per frame.

Version assumption: current stable Flutter. Exact scheduler internals can shift between minor versions, so verify against your installed release.

Confirmed facts vs. likely explanation

Confirmed: SchedulerBinding owns frame scheduling. setState() adds the widget to the dirty list and requests a frame. Multiple requests before the next frame start collapse into one build phase. Debug builds assert against reentrant setState() during an active build; profile and release builds may defer silently, but the coalescing contract is unchanged.

Likely explanation: your sensor stream or interaction handler is issuing several setState() calls between VSync boundaries. The UI isolate sees one dirty set and renders one frame, so intermediate logical states never reach the screen. GPU raster backpressure can cause separate jank, but it is not the cause of coalescing.

Steps for this case

1. Confirm whether the rapid calls originate from the UI isolate or a background isolate; background messages add a scheduler hop before setState() runs.
2. If every logical update must be visible, schedule the next setState() after the current frame ends.
3. Avoid calling setState() again from inside a build. Schedule from the event handler, timer, or stream listener that owns the logical update.
4. Do not attempt multiple builds in one frame; Flutter’s pipeline does not support it and workarounds usually trigger reentrant-build asserts or skipped frames.

SchedulerBinding.instance.addPostFrameCallback((_) {
  setState(() {
    // apply next logical update
  });
});

DevTools correlation

Open DevTools Performance and record while reproducing the rapid updates. Correlate these timeline events:

Event	What it tells you
Frame Start	Marks the beginning of a new UI frame.
Build	Runs once per frame for dirty widgets. Multiple setState() calls before this point indicate scheduler coalescing.
Raster	Render-thread work. If Build finishes quickly but Raster is late, the bottleneck is GPU or render-thread backpressure, not Dart scheduling.

If several setState() timestamps fall between one Frame Start and the next Build, you are seeing coalescing. If Build is immediate but Raster trails, investigate render-thread load instead.

Missing diagnostic detail

Are the rapid setState() calls posted from the UI isolate or a background isolate? This changes whether you need to optimize isolate message passing in addition to frame scheduling.