I am currently creating a flappyBird-like HTML5 game using Proccessing.js

You can see current work here: http://files.tips4design.com/flappySlothRelease/

The problem is that even though the FPS is 60+ (or constant) there is an obvious shuttering in rendering.

I have read a lot of game-loop articles to solve this issue, but neither with Processing.js draw loop, browser's requestAnimFrame nor constant delta-time the problem was solved.

Now I use the variable deltaTime approach and Processing.js default draw() loop.

delta = now - lastTime;
position = position + velocity * delta

I have been stuck for two days with this problem, and ca not really figure out how to fix the shuttering.

Any help would be greatly appreciated!

Thank you!

  • \$\begingroup\$ I don't see any stuttering. (Chrome) \$\endgroup\$ Commented Feb 21, 2014 at 12:01

2 Answers 2


requestAnimationFrame implementation depends on browser solely. Browser will try to reduce framing if it "believes" that it will be better for user, and usually does it "smoothly" from 60 to 30. But that shift is obviously easy to see. As well once it is some time in 30fps state, it then usually shifts back to 60. The problem here is that this shifting is very bad for player experience, and it is recommended to use persistent FPS rather than shifting.

I personally did benchmarks with canvas, and use setInterval solely, as found no actual performance advantage using requestAnimationFrame in real game examples.

This will stabilize you frame rate, but you need to handle delta time which is:
var dt = (now - last) / (1000 / 60);
Assuming your target FPS is 60. That will give you number around 1.0, more - is more laggy, and less is over-performing target fps. You will have to multiply your most time based operations by this value.


make sure you are not creating objects in your render-loop this can cause memory leaks as well as stuttering and slow-downs.

I checked your source for data/main.js and it looks like your not doing anything improper besides maybe var auxDate = new Date(); you could put auxDate outside the render loop because each iteration its being re-created and could cause some slowdowns.

  • \$\begingroup\$ why the downvote? \$\endgroup\$
    – Mouseroot
    Commented Feb 24, 2014 at 7:18
  • \$\begingroup\$ I have actually updated the game so I do not create any objects during the game. I first create 3 sets of obstacles (trees) and then when an obstacles goes of screen, instead of deleting it and adding another one to the right I simply move that obstacles to the right. I also updated the render loop to only re-draw the parts that have been updated (not redraw everything starting with the background). I think one problem might be the speed of the moving objects. If an object has to travel 100pixels in 1 second and there are only 60FPS there might seem to be some lag... \$\endgroup\$
    – Cristy
    Commented Feb 24, 2014 at 7:39
  • \$\begingroup\$ if that's the only issue, you may want to look into double buffering, not sure if you can really implement that with processing.js but if you can it would help that lag or tearing as some may call it. because you would render your scene to another offscreen/hidden canvas and then render whats on the offscreen canvas onto your visible one. \$\endgroup\$
    – Mouseroot
    Commented Feb 24, 2014 at 7:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .