3D at 120 frames a second
3D pages run at the full rate of a 120 Hz screen. Every few seconds the browser tidied a page that was still animating as if it were idle, throwing away its compiled code, so the next two frames rebuilt it and the scene stuttered. It now leaves an animating page alone. The heaviest 3D page we test uses a third less of the processor, because the objects a 3D library builds keep their fast layout and their methods are found without a search. Some 3D models showed nothing at all and now appear, and WebGL passes 95% of the official conformance pages.
Models that showed nothing
A 3D model loaded quickly here and then the page stayed black, while the reference browser showed it at once. The model file carries a block of XMP metadata, and the loader reads it with getElementsByTagName on names like rdf:Description. We matched the tag by its local name only, so the loader found nothing it expected and stopped. Tag names now match the way the standard says, the whole qualified name.
120 frames a second, and why it was 110
Three of four 3D test pages ran at 109 to 112 frames a second on a 120 Hz screen while using under half a core, so the processor was not the limit. A log of every frame showed the time was lost in stalls of 40 and 65 ms every four seconds. The idle tidy-up, which packs a quiet page away to save memory, also ran on a page drawing animation frames, and it threw away the page's compiled code. A page that wants frames is not idle any more.
A third less work on the heaviest 3D page
Counting every property read that took the slow general path on the animated keyframes page found 22 million in 25 seconds. The 3D library's scene objects were stored as dictionaries, because defineProperty removed attribute markers that had never been set, and every removal changed the object's layout. Methods on class instances and checks for properties an object does not have were never cached. With those fixed, a call over a list holding meshes, lines and points stays in compiled code instead of falling back.
95% of WebGL conformance
We ran the official WebGL 1 conformance pages one by one and fixed what they found: a draw with an enabled attribute and no buffer, a draw after a failed relink, reserved names, copies into the texture being read, losing and restoring a context, ties in clamped bytes, and workers that could not load scripts or pass a DataView.