Main Thread vs. Background Pool: Frame Budget Simulator

Task Generator

Task cost 40 ms

Spawn rate 4.0 / s

Worker pool size 3 threads

Route New Tasks To

Live Readouts

Simulated UI frame rate

60.0 fps

Dropped frames

Pool utilization

Main queue / Pool queue

0 / 0

How it works

A mobile UI must redraw roughly every 16.67 ms to hold 60 fps — that budget is the entire life of one frame:

frame_budget = 1000 / 60 ≈ 16.67 ms
dropped_frames(task) = ⌊cost_ms / 16.67⌋ − 1   (if task runs on the main thread)

Real platforms keep exactly this separation. iOS's Grand Central Dispatch has one serial main queue for UI plus concurrent global queues for background work; Android has a single UI thread plus a thread pool Executor, and Kotlin coroutines schedule onto Dispatchers.Main vs Dispatchers.Default/IO. A task queued on the main thread blocks every frame until it finishes — this sim models that by freezing the spinning app-icon and counting the frames that should have rendered but couldn't. A task routed to the pool runs on whichever worker lane is free, in parallel with the other workers and fully independent of the UI thread, so the icon keeps spinning at a steady 60 fps no matter how busy the pool gets.

Task cost — how long one simulated unit of work takes (e.g. JSON parsing, a DB query, image decoding).
Spawn rate — how many new tasks arrive per second, feeding whichever destination is selected below.
Worker pool size — number of parallel background threads sharing the pool's incoming queue.
Route new tasks to — toggles the classic mobile-dev mistake (heavy work on the UI thread) against the fix (offload to a pool), live.

Pool utilization is the fraction of the last second that the average worker spent busy — near 100% means the pool is saturated and tasks start queuing even though the UI stays smooth.

SMOOTH

Main (UI) thread lane Worker pool lanes Task currently executing

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.