HTML5 Jump and Run Game Performance issues

Question

we're developing a HTML5/Javascript jump and run game and therefore we have developed our own gameframework. It consists of following most important structures:

• Stage/Scene/Layer: divs
• ObjectEntites/Rectangle/Sprite: canvas

In the gameloop things get moved by calculating an offset value: e.g. if we place a coin and this coin moves through the screen, it gets a new offset in each gameloop-call. The dirty area of the coin is cleared in the canvas and the coin is repainted. We pay attention that we just draw at int-values (no floating point).

Unfortunately we have some performance issues now and can't figure out why our macbook pro's are running hot while playing the game.

Are the drawing operations so crucial? We have layered Canvas, so just moving stuff gets repainted and even not the whole canvas but just dirty-areas get cleared.

IStat shows following values while playing the game: Memory module A1 and Heatsink B get up to 60° and the rpm-Value of the Fans increases up to 3000-4000. In firefox we see these values:

And chrome shows us this, where we also see how cpu increases:

Do you have any idea how to check performance of our game, how to find bottlenecks or general tips? We have searched for canvas performance, used firebug profiler... We'd be grateful for any advice!

Answer 1

I recently watched a Google I/O 2012 video (http://www.youtube.com/watch?v=Prkyd5n0P7k) which talks about using an off-DOM canvas to perform your rendering, then "blitting" that canvas to an on-DOM canvas for final presentation. The speaker indicates their game saw a 30X performance increase simply by using an off-DOM canvas. YMMV, but maybe this will help you out.

Answer 2

It doesn't seem that you have a real issue.

The exact amount depends on the browser, but pretty much all over the line canvas is a compute expensive tool relative to the number of pixel you push through.

Your CPU gets hot, that is to be expected if you do anything moderately complex with a canvas.

I'm not saying that there necessarily isn't something smart you can do to decrease the processing required, but from the very moderate amount of information you give about your game I don't see any red flags.

Answer 3

Moving canvas is generally slow: differents browser has different performance issue, but moving just a big background image in enought to slow down the frame rate.

If you are supposed to perform real time, i suggest you to use webGL or equivalent.

How to check performance:

• Time in drawing SVG: monitoring all changes may help to know what operation is expensive. Also check that you optimize your code with: id = mySvg.suspendRedraw(x) and mySvg.unsuspendRedraw(id). See http://dschulze.com/blog/articles/4/efficient-redrawing-on-svg-or-why-suspendredraw-is-a-lie and set svg quality to low/fast.
• Time in database: never mix lot of rows with lot of data per rows. Divide queries in sub-queries that get ids and then get only interesting rows.
• Javascript usually does not take lot of time, but if you expect a function is taking lot of time, monitoring it and try to optimize it (for example with asm.js)

Answer 4

If i understand well you have all your gfx in canvas.
So it doesn't seem difficult to have the behaviour of the divs handled by some hand made class that will handle scene/layers. This way you can have the whole scene draw on a single canvas and avoid costly dom layout computations.

You might even have the context do a part of the job for you :

   // takes x,y,scale and a list of elements (which might be Scene)
   function Scene(x,y, scale) {
       this.elements = Array.prototype.slice.call( arguments, 0);
       this.x = x;
       this.y = y;
       this.scale=scale;
   }

   Scene.prototype.draw(ctx) {
       ctx.save();
       ctx.translate(this.x, this.y);
       if (this.scale !=1) ctx.scale(this.scale, this.scale);
       // rotate clip, ... here
       for (var i=0; i<this.elements.length; i++) {
           this.elements.draw(ctx);
       }
       ctx.restore()
   }

or you can have the elements compute their position based on their parent's.

Anyway i bet it will be much faster.