- Shipped
- September 5, 2026 at 7:05 PM UTC
- Author
- Kamo
- Commit
- 70d068c
A conic gradient centred on the pane, spun once per --glimmer-period, painted twice: a sweep filling the 15px gap, and a 2px rim on the pane's own border. The rim is the half that sells it — a glow in the gap alone reads as a background effect, whereas an edge catching the light as the sweep passes reads as a lit object, and the pane's rounded corners lighting up in turn is the whole trick. The stops are a specular sheen rather than a glow: a band of shade, a hard rise through cool into a blown-out core a few degrees wide, a fast fall through warm, then shade again. The shade is not decoration. White on a #cdcdcd gap has almost no headroom to read as a highlight on its own, so the contrast has to be built by darkening what surrounds the core; the first cut had none and read as a wash rather than a glimmer. Written as a rotation, not as an animated angle. The obvious implementation animates a registered <angle> custom property into `conic-gradient(from …)`, and this did, until an interleaved A/B against the same page with the glimmer removed showed the median frame time going from 33.3ms to 50-66ms: that form repaints the gradient across the element's whole box every frame. Rotating an element that carries a fixed gradient makes the raster a one-off the compositor reuses. Chrome's own metrics then show no added main-thread time and no layout at all, and what frame cost remains here is software rasterisation — this machine composites through SwiftShader, with no GPU to do it for free. Dropping @property also removes the one browser-support cliff in the feature. Where it is unsupported the angle cannot interpolate, so the sweep would have stood still rather than degrading to nothing. Each layer is a clipping wrapper around a spinning square. The square is sized in vmax because it must cover its wrapper at every angle, which takes the wrapper's diagonal — at most root two times the larger viewport axis. Under prefers-reduced-motion both are display:none rather than frozen, because a bright arc parked in one corner reads as a rendering fault, not as a decision. Verified at 1440x900 and 390x844 with the animation paused at chosen times: the core crosses the top edge and the top-right corner where the geometry predicts, the rim measures 2px of white at 8x zoom, and reduced motion leaves zero spin animations running.