CODEWITHSUNDEEP
javascriptcanvas
Sunwoo Yang
Sunwoo Yang

Reputation: 1243

Canvas/Javascript periodic slow downs only at beginning

I've been having trouble using the canvas element and can't seem to locate the problem.

The slowdown happens every 5-15 seconds when the page is initially loaded. But, after tabbing over to facebook for a while and chatting with friends, it miraculousy stopped exhibiting slow downs.

My friends also see the periodic slowdowns and they use chrome/firefox

I have no idea what's happening! I'm reading up on memory leaks/heap profiling, but I'm having a hard time locating the problem.

I initially only had one ball bouncing around, but I decided to put in 1000 balls to try and test performance, sorry :P

EDIT1: Ok, I tried running the same code on Firefox(i've been using chrome) and the balls are moving significantly slower on firefox minus the horrible stutter I've been seeing on chrome... What's causing the browsers to use different speeds for the balls?

WARNING WARNING EPILEPSY WARNING Link to live demo

Here's the code

Upvotes: 1

Views: 124

Answers (1)

DerekR
DerekR

Reputation: 3986

Because you are using request animation frame it will try to hit 60 fps, and if it can't then it will settle for 30 fps, until it can deliver 60 fps. So the slowdown is your canvas running at 30 fps, and the jump to 60 fps makes things seem to speed up.

The reason why you're only hitting 30 fps in the beginning can be varied. In my case my computer is plenty powerful but I've got multiple monitors and I just opened the example in a new window on a new monitor, I suspect my OS limits only 1 monitor at a time to 60 fps unless I'm full screened in a game that takes up all 3 monitors. But this is not your problem, I just use it as an example as to why you need to be profiling and running performance tests yourself on a variety of setups, because there are any number of things that can be causing performance problems.

One of the reasons you get a perceived "slow down" and "speed up" is because you're updating positions on a frame by frame basis, but the time in between frames varies from 33ms to 16ms depending on what the current frame rate is. It would be advisable to make all of your update functions use the delta time (or the elapsed time since the previous frame) as a measure of how much to update the positions.

What you have:

Ball.prototype.update = function() {
  this.x += this.velocity.x;
  this.y += this.velocity.y;
}

We want to include a delta time in here

Ball.prototype.update = function(deltaTime) {
  this.x += this.velocity.x * deltaTime;
  this.y += this.velocity.y * deltaTime;
}

The only difference here will be that you're going to have to express your velocity in relation to time. For example, your velocity will be expressed as 100 pixels per second, and your delta Time will be expressed in seconds as well (with a value of around .016 or .033)

This won't fix the 30 fps but it will make your balls move at a consistent speed. When you first load the page, the browser needs to load all the other scripts you're including, parse and evaluate them, and in some cases will fire off some Garbage Collection (as is the case with the included jQuery). If you don't need jQuery or other such additional files you can avoid including them.

More importantly, you don't have to start rendering full speed ahead as soon as the page loads. In the case of games, they'll have their own loading screens and title screens preceding actual game rendering that players won't be able to tell the difference between 30 fps and 60 fps on anyway.

Upvotes: 1

Related Questions