Blog · · 7 min read
A WebGL hero that does not stutter
Frame pacing, draw-call budgets, camera-parented lights, and knowing when to stop rendering entirely.
The cube on the front page of this site went through several rewrites before it felt smooth. Most of the problems were not GPU limits. They were scheduling mistakes of my own making.
Never skip frames to save frames
My first attempt capped the animation at 30fps by returning early from the animation callback. Uneven frame intervals read as stutter far more than a lower steady frame rate does. Rendering every frame with a correct delta was immediately smoother.
Count your draw calls
Twenty-six cubes each carrying their own wireframe overlay meant fifty-two draw calls, half of them blended. The gaps between the cubes already read as edges, so the overlays were paying a real cost for nothing.
Parent your lights to the camera
A rotating object under fixed lights will eventually turn its unlit side toward the viewer. Attaching the light rig to the camera keeps the visible face lit no matter where the rotation lands.
Stop rendering
When nothing has changed, drawing the same frame again is pure battery cost. A few idle frames after motion settles, the loop stops calling render at all.