Indeed. It is rare to encounter a webgl/gpu visualization that doesn't rev up the fans at 100% while sitting idle, let alone to have this low latency handling input. Virtually all web demos I have seen run terribly because literally 0 attention is paid to actual rendering. The other day somebody submitted one here and admitted they didn't know backface culling was a thing. They also almost universally have no sort of frame pacing.

I find zooming on this world capitals one to be quite slow for some reason, mostly well below 10fps, and it’s rendering all frames rather than skipping to keep up (the wrong decision, I reckon). Panning is excellent; and zooming is fine on /maps/voronoi/, which has only a dozen or so points, which I guess must be few enough not to slow it down. I’m curious what’s going on, but not enough to delve into the code myself.

Actually, even /maps/voronoi/ lags if you zoom in really far, and in a way that can break the scroll capture—I presume the code is non-passively watching scroll events and calling preventDefault(), but once it’s lagging hard enough the browser takes matters into its own hands and says you didn’t act fast enough.

It feels quite choppy on mobile, but I think it could be fixed by adding touch-action: none