RepaintBoundary placement for a Flutter list with animated tiles: how many layers is too many

Answer

For a mostly static ListView with only a few tiles that animate each frame, the practical limit is “as few boundaries as you actually need”. In Flutter 3.x each RepaintBoundary creates its own composited layer and GPU backing store, so adding one per visible item quickly outweighs the repaint‑saving benefit.

Confirmed facts

• A RepaintBoundary isolates its subtree into a separate layer; repaints inside do not dirty ancestors.
• The framework already inserts boundaries around slivers, viewport children and some animated widgets, so a manual boundary can be redundant.
• When a ListView.builder item scrolls off‑screen and its render object is disposed (default addAutomaticKeepAlives behavior), the layer and its backing store are released.
• The DevTools Repaint Rainbow shows which layers actually repaint each frame; the raster thread timeline shows the cost of compositing those layers.

Likely explanation / heuristic

1. Identify the subtrees that repaint on most frames (e.g., the progress indicator and the chart).
2. Wrap each of those subtrees tightly in a RepaintBoundary – do **not** wrap the whole list item or the static surrounding content.
3. Leave static list items without a boundary; let the framework’s existing boundaries handle them.
4. If you have more than ~5‑10 animated tiles that each need a boundary, start measuring; beyond that the per‑layer memory (≈ 4 MB per layer on typical devices) and raster overhead usually outweigh the gain.
5. Verify with DevTools: enable debugRepaintRainbowEnabled (or the Repaint Rainbow toggle), run the animation, and confirm that only the wrapped tiles flash while the rest of the list stays static. Then compare the raster thread frame time before and after adding the boundaries; a flat or decreasing raster time indicates a net win.

Steps for your case

1. Remove any RepaintBoundary that currently wraps entire list items.
2. Add a boundary directly around the animated widget inside each tile (e.g., RepaintBoundary(child: ProgressIndicator(...))).
3. Run the app in debug mode, enable Repaint Rainbow, and watch for flashing only on those widgets.
4. Open DevTools → Performance, record a trace while the animation runs, and note the raster thread frame time (ms).
5. If raster time stays the same or drops and memory does not grow with visible item count, the boundaries are helpful. If raster time rises or memory climbs, remove the boundaries and instead throttle the animation or chart updates.

Ask for one missing diagnostic detail only when it changes the recommendation: if you are targeting a device with very limited GPU memory (e.g., low‑end Android 512 MB RAM), let me know the exact memory budget so we can adjust the safe number of boundaries.