Breath of the Wild on an iPhone dropped to 30 fps after cutscenes (pipeline compiles stepped the
hold up) and stayed there for 36 and 46 s until the player switched out and back. At hold 2 its
GPU time was 12.8-15.2 ms a frame (p50), where hold 1 had held for minutes: the iPhone lowers the
GPU clock until the work fills most of the frame, so a GPU-bound game's cost sits near the fit
line (0.85 of a vsync) at either hold and the fit trial never fires. The same 4,900 draws took
5.8 ms right after a trip to the background and 13.5 ms half a minute later.
nvn_fstep.h now keeps the running cost of the frames on time at kmin. A step up after a run of
8 s (FSTEP_HOLD_MAX) or more at kmin keeps it as cref; when the cost of the frames on time at the
longer hold (30 frames or more) is at most FSTEP_SAME (1.1) times cref, the scene costs what it
did and a probe starts after the hold-off (nvn_fstep_same). A run under 8 s keeps no cost, so a
device that steps up every few seconds stays at 30 rather than flap. Log: "(probe, cost 1.04x
the cost that held hold 1)", and "; hold 1 held at 0.86" on a step up.
DM_TEST_PRESENT_LAG takes runs and several entries ("1,11;1200,40,3": 11 ms on every frame, 40
more on three in a row every 1,200 presents), which imitates the hitch on the Mac.
t_fstep 47/47 (8 new checks; 4 fail with the rule off). Mac (M4 Pro), BotW with that lag, 170 s:
the old host held 30 from the first hitch in gameplay to the end; the new one was back at 60
within about 1 s of every hitch (9 of 11 probes held, the other two cut short by the next hitch),
game time 1.000 of real time.
IPA ZeldaBreathOfTheWild-2026-10-21-hitch.ipa (fps counter on) awaits an iPhone test.