Forty animated backgrounds, one battery budget: how Pairly rations frames on old Android

The budgeting all happens in one function, `getPerformanceProfile`, and its comparisons are ORs rather than ANDs ^[9][10][11]. A device reporting eight cores and a memory value of 16 satisfies `cores <= 8` and is placed in medium, capped at 60fps with a 0.7 particle multiplier; reaching high requires more than eight cores and more than eight units of memory at once ^[6]. Erring downward is the safe direction, but a lot of current phone hardware will sit a tier below what it could drive. Both readings also fall back to 4 when the browser declines to answer, and 4 satisfies the low branch, so a browser that exposes neither value gets 30fps and 45 percent of the particles no matter what silicon is underneath ^[8][7].

The accumulator and the pixel-ratio cap are where the savings actually are. On the low profile the frame interval is 33ms while requestAnimationFrame on a 120Hz panel fires roughly every 8ms, so about three of every four callbacks exit before touching the context ^[1][2]. The cap does more: 1.25 squared is 1.56 times a 1x buffer, against the 16x the author attributes to a native 4x-DPR phone, which is 10.2 times less area to fill on each frame that does draw ^[14][15][3]. Multiply the two and a low-tier device is asked for about one forty-first of the per-second pixel work a naive native-rate, native-resolution loop would demand ^[4], before the 0.45 multiplier takes a further 2.2x off per-object cost ^[12][5]. Numbers that size are the argument for centralising them: no individual effect author should be expected to rediscover any of it ^[5].

What the engines do not absorb is the floor. The count formula keeps `Math.max(minCount, ...)`, so each atmosphere still declares the point below which its own effect stops reading as itself ^[12]. And the picker is a second implementation of the same idea in another technology, CSS keyframes standing in for ten or more live canvas loops ^[19]. That is the right call for a grid of tiles, and it also means every atmosphere past the current forty-plus needs two visual definitions that agree with each other ^[2].

Worth being clear about what the write-up is: architecture, not measurement. The DPR cap is described as one of the single biggest performance wins in the system ^[16], with no frame times or battery figures attached, and no named test device ^[20]. The five-year-old Android phone is the stated target ^[3], not a reported result. The disclosure deserves its own look, too. Users on downgraded hardware see one line, "We've simplified effects to keep things smooth on this device", and get no control over the decision ^[13], while the density slider they can see is a request the engine is free to scale down ^[12][13]. That is defensible for a chat background. It becomes a support problem the first time two users compare screens.