Are you open to a PR to update Octo to use the requestAnimationFrame() API? I’m seeing weird rendering glitch with Chrome (and can’t unsee it now). The problem is that the GPU rendering is not GUARANTEED to be in sync with your setInterval… yes, this surprised me also, I even added a frame counter to make sure I wasn’t insane… so what usually happens is:

setInterval -> GPU paint -> setInterval => GPU paint

But every once in a while you end up with two setIntervals before the next GPU paint:

setInterval -> GPU paint -> setInterval => setInterval -> GPU paint

And then my pixel perfect animation glitches. :-) This is exactly the problem requestAnimationFrame was intended to solve - calling animation code immediately (guaranteed) before the next GPU paint - so you’re always in sync.

Thoughts?

You can see it in the last frame… the GPU rendering was happening just a bit before the JS event but then slowly it shifts and then it slides in front of the update instead, and then we have a skipped frame.

I'm willing to consider it, but such a patch would need careful testing across browsers. It substantially complicates delivering updates at a fixed framerate, since it typically respects the refresh rate of the display.

Keep in mind that it would be necessary to patch both the main loop in octo itself and the one in the standalone stub.

There's a large corpus of programs which could be used to test changes on the chip8 archive. As I recall, the program Piper is particularly fragile, since it uses an unusual approach to framerate control.