> The core issue is that browsers are real-time systems. They render frames when they can, skip frames under load, and tie animations to wall-clock time. If your screenshot takes 200ms but your animation expects 16ms frames, you get a stuttery, unwatchable mess.

But by faking the performance of your webpage, maybe you are lying to your potential users too?

> But by faking the performance of your webpage, maybe you are lying to your potential users too?

I think you're missing the point of it a little. The "user" is someone who wants to watch a rendered video of the brower's display, but if it takes longer than one frame (where you read the word frame in this comment, think of a frame of video or film, not a browser "frame" like people used to make broken menus with) to actually draw the visual the browser will skip it.

Instead this appears to just tell the browser it's got plenty of time, keep drawing, and then capture the output when it's done.

It's not too different to how you'd do for example stop motion animation - you'd take a few minutes to pose each figure and set up the scene, trip the shutter, take a few more minutes to pose each figure for the next part of each movement, trip the shutter again, and so on. Say it took five minutes to set up and shoot each frame then one second of film would take an hour of solid work (assuming 12 frames per second, or "shooting on twos").

It's just saying "take all the time you want, show me it when it's done" and then worrying about making it into smooth video after the work is done.