Fix ecs_progress blocking when the clock does not advance between frames

[simon112]

(AI-authored fix; verification described at the bottom.)

Problem

flecs_start_measure_frame retries measurement in a loop until the clock returns a nonzero delta ("Keep trying while delta_time is zero"). Two consequences:

• On a clock that is too coarse to measure a short frame (a browser with reduced timer precision, a coarse OS tick), every frame that finishes within one clock quantum busy-spins reading the clock until the quantum passes: frame times get pinned to the clock quantum, with a core burned doing it.
• On a clock that only advances when the host steps it in between frames (deterministic simulations, replay harnesses, any custom get_time on a virtualized timeline), the loop never exits and ecs_progress() blocks forever.

The loop dates from f1164f4 (2019). At the time, a zero measurement risked losing the elapsed time, so retrying was the conservative choice. Measurement has since come to preserve the frame start time across a zero reading (ecs_time_measure writes back a value-identical timestamp when the clock did not advance), which is what makes it safe to stop retrying.

Fix

A zero measurement now reports a minimal nonzero delta (ECS_FRAME_MIN_DELTA_TIME, 1e-9) instead of measuring again. Since the frame start anchor is preserved, the elapsed time is credited in full to the frame in which the clock next advances: summed deltas still equal actual clock movement (the new coarse-clock test asserts conservation both ways), and the only distortion is the 1e-9 per stalled frame itself. The first frame that reports the minimum logs a warning, once per world: a rate computed by dividing by the minimum is a plausible looking number rather than the inf a zero would produce, so the loudness that a zero delta would have provided moves into the log instead.

Why an epsilon and not a fabricated fallback such as 1/60: a fabricated delta advances simulation time that did not pass, which on a fixed-timestep simulation against a stepped clock injects unbounded invented time. The epsilon keeps world time within 1e-9 per frame of what the clock actually reports. Callers that divide by delta_time still never see zero, and a tiny delta is not a new hazard class for systems: upstream already has tests asserting delta_time == 0 paths (time_scale 0, OnStart).

Two adjacent fixes ride along:

• The first-frame branch is now selected by a world flag (EcsWorldFrameStartTimeSet) instead of testing the frame start time against {0,0}, which pinned a simulated clock that legitimately starts at zero to the first-frame branch forever.
• The world summary computed fps as 1.0 / delta_time_raw, which is inf before the first measured frame (not representable in JSON on the REST endpoint) and a rate in the billions on stalled frames. It now reports 0 when no measurable frame time exists, and the windowed fps gauge in the stats addon applies the same threshold, so a stats window averaging at or below the minimum delta also reports 0 rather than the reciprocal of the minimum.

Tests

World_progress_w_stalled_clock, World_progress_w_stalled_clock_at_zero, World_progress_w_coarse_clock (conservation with upper and lower bounds, plus clock read-count bounds so a measurement path that spins or gives up fails rather than passes), and Stats_world_summary_fps_w_stalled_clock. The stalled-clock tests hang on current master by construction.

Note: with a target FPS configured, a stalled clock still blocks in flecs_insert_sleep. That is a separate defect in the frame rate limiting loop with its own fix and tests, submitted as a follow-up PR (based on this branch); its tests would hang this PR's CI, which is why the fps-variant tests live there.

Verified with the full test/core and test/addons suites on Linux, in debug and sanitize builds. The new World tests also pass on Windows/MSVC. distr/ regenerated from a clean tree.

🤖 Generated with Claude Code

[simon112]

[Edit: below being written by AI, as was everything else in this thread except this edit, the WASM application also being vibecoded by me (but AI sessions in different folders treat each other as separate projects), permission being from me.]

For the record, a field signature of this wedge from a downstream WASM application (shared with permission), in case anyone else is trying to match a report against it:

• 100% CPU, flat heap, no allocation; the main thread never returns from ecs_progress.
• Their watchdog caught it as clock_probes=374359949 against alloc_probes=8821 over the stall, roughly 37M clock reads per second with the clock standing still.
• The Firefox profile shows a single unbroken multi-second block under the frame tick with the OS time function beneath it, which they misread for a while as a profiler artifact.

The host was Emscripten, where performance.now() resolution clamping makes equal consecutive reads routine, so this matches the stock-WASM path described in the PR: no custom clock is needed to hit it.