Limiting WebGL Framerate via setInterval severely decreases performance - performance

Question

I am creating a webgl game, I have it fairly well optimized, however there is one problem, my framerate limiter destorys performance. I know what your thinking "duh, of course it is...its an fps limiter". Well the issue is that it is not behaving at expected. Here is the code:
renderTimer = null;
function animate() {
clearTimeout(renderTimer);
renderTimer = setTimeout(function () {
_frame = requestAnimationFrame(animate);
}, 33);
render();
}
function render(){
// operations for mesh positioning/animation
handleObjects();
renderer.render(scene, camera);
}
On my desktop this works as expected, gameplay is smooth and is held at 29-30fps.
On my laptop fps drops to 22-24 and gameplay is jerky. If I change the interval delay to 16ms, gameplay is relatively smooth and holds at about 35fps. If I remove the interval all together gameplay is completely smooth and holds at about 45fps.
I dont completely understand this behavior. If the cap is 30fps why does my laptop performance drop below 25fps? I would expect it to be also 25fps without the interval, but yet it goes faster. Curious.
I would happily just remove the interval however I do want my fps capped at 30, players getting a higher fps than that would be at an advantage.
Thoughts?

Answer 1

There are a couple of considerations:
setTimeout in javascript can not really be counted on being very accurate.
Browser can do it's own things like garbage collection at any time, delaying stuff.
Rendering itself (webgl/three.js + your own game logic) takes time. Even though you create the timeout before main render call, it still introduces 33msec idle time.
Well, I'm not actually sure about the last point, now that I think about it. Anyway I have observed similar problems, and I managed to make a solution that works pretty OK, it will keep the framerate smooth and +/- 1-2 FPS accurate to a target framerate if the computer can handle such framerate at all. It's a hack though.
First you could take a look at the requestAnimationFrame implementation in Three.js (for browsers that do not have it built-in):
requestAnimationFrame = function ( callback ) {
var currTime = Date.now(), timeToCall = Math.max( 0, 16 - ( currTime - lastTime ) );
var id = self.setTimeout( function() { callback( currTime + timeToCall ); }, timeToCall );
lastTime = currTime + timeToCall;
return id;
};
You can see it adjusts the setTimeout based on the last call (targeting around 60FPS). So that's one solution you could try.
What I did (the hack that seems to work well), is to have the timeout value as a variable, with initial value being the original 33 or whatever the desired framerate is. Then on each frame, I record the Date.now(), and compare it to the previous frame time. If we missed the budgeted frame time, we decrement the timeout value by 1. If we were faster than desired, we increment timeout by 1. So the code is continually, smoothly, adjusting the timeout to match desired framerate. By only slightly incrementing/decrementing, we avoid the problems with unpredictable garbage collections etc completely throwing off calculations and messing things up. And it just works (tm)
I won't post the code because there is so much more going on my render loop (only render new frame if something is changed etc), it would be tedious to isolate a relevant code example.