Replace setInterval with setTimeout for animation loop

[vorg]

Can we consider replacing setInterval(function() {
obj.redraw();
}, 1000 / fps);

with something similar to requestAnimFrame where setTimeout would be called at the end of obj.redraw? Right now if I render something heavy that takes more that 1000 / fps milliseconds the app becomes so unresponsive that is even hard to close it.

[deanm]

I don't think this really does what you want, if you want 30fps, then you should push a frame every 33ms. But if you take 10ms to prepare that frame, then you would only be running every 43ms (10ms then plus 33ms for the timeout). Or is the idea to measure how long the processing took and adjust the timer? If the draw interval is starving other events that's something else to look into I think (maybe libuv has a specific preferred processing order?)

[vorg]

Hi,

Or is the idea to measure how long the processing took and adjust the
timer?

This is a good idea. I just though about the same during morning run. I'll
try it out. Also if I implement fps throttling in my lib it won't be Plask
specific and should work in the browser as well.

Marcin Ignac
http://marcinignac.com
@MarcinIgnac

[notlion]

How hard would it be to implement an actual requestAnimationFrame function that's hooked into vsync events? Probably easier on OS X, as usual? Found a relevant page in the Core Video docs..

[deanm]

I don't think requestAnimationFrame is really a good comparison, since generally it's part of a huge browser rendering and compositing infrastructure that doesn't apply to Plask...

On OSX the thing to use is displaylink. The thing is in order to get timing right you also need to factor in how long it will take you to prepare/compute the frame, so that you hit the vsync on time. This is why it's always pretty tricky... I will have to do some more research on it.

[notlion]

In this talk (link should skip to the right part) from Google I/O 2012 they seem to suggest that just having CPU animation triggered by syncs will make sure the render is ready to be pushed to the display by the next sync. That's assuming your animation runs in less than 1/60hz or whatever your refresh rate is, which is basically the same as setInterval, just more resilient to occasional long frames.

[deanm]

The difference for Plask is that the rendering isn't decoupled, so if we fire the timer at the end of the last vsync, and you take 1ms to prepare the frame, you then wait 32ms (assuming 30fps) in glSwapBuffers. Allowing the event loop to run and do something during the 32ms is something I want to try to design in.