Improving Html5 canvas with double buffering?

Question

I'm writing a game in javascript canvas, and I experience lag sometimes. I think this is because I draw pretty much to the canvas.

My background for example isn't static, it moves from the right to the left, so each time, I have to clear the entire canvas. And I'm not clearing with just a color, I'm clearing with an image that moves every cycle of the gameloop.

I think this is an expensive operation and I was thinking if there is something to make this operation less expensive, like for example using double buffering for clearing the background (no idea if you can use double buffering just for clearing the background?).

Or should I use double buffering in the entire game? (I don't think so because I've read that the browser already does that for you)

Answer 1

Since you experience your lag 'sometimes', and it's not a low frame rate issue, i would rather move my eyes towards the evil garbage collector : whenever it triggers, the application will freeze for up to a few milliseconds, and you'll get a frame miss.
To watch for this, you can use google profiling tools, in TimeLine / Memory / press the record button : you can see that a GC occurred when there's a sudden drop in the memory used.
Beware when using this tool, that it slows down a bit the app, and it creates garbage on its own (!)...
Also, since any function call for example creates a bit of garbage, so you can't have a full flat memory line.

Below i show the diagram of a simple game i made before i optimized memory use,
there's up to 5 GC per second :

And here the diagram of the very same game after memory optimisation : there's something like 1 GC per second. Because of the limitations i mentioned above, it is in fact the best we can get, and the game suffers no frame drop and feels more responsive.

To avoid creating garbage
- never create object, arrays or functions.
- never grow or reduce an array size.
- watch out for hidden object creation : Function.bind or Array.splice are two examples.

You can also :
- Pool (recycle) your objects - use a particle engine to handle objects that are numerous / short lived.

I made a pooling lib (here) and a particle engine (here) you might use if you're interested.

But maybe first thing to do is to seek where you create objects, and have them created only once. Since js is single-threaded, you can in fact use static objects for quite a few things without any risk.

Just one small expl :

function complicatedComputation(parameters) {
   // ...
   var x=parameters.x, y = parameters.y, ... ...
}
// you can call creating an object each time :
 var res = complicatedComputation ( { x : this.x, y : this.y,  ... ...  } );

 //... or for instance define once a parameter object : 
 complicatedComputation.parameters = { x :0, y:0, ... ... };

 // then when you want to call :
 var params = complicatedComputation.parameters;
 params.x = this.x ; params.y = this.y; ... ...
 var res = complicatedComputation(params);

It has the drawback that previous calls parameters remains, so you don't get undefined if you don't
set them, but previous value, so you might have to change bit your function.
But on the other hand, if you call several times the function with similar parameters, it comes very handy.

Happy memory hunting !

Answer 2

Double buffering is a technique to reduce flickering: You draw to one buffer while another buffer is displayed, and then swap them out in a single operation, so the user doesn't see any of the drawing in a partial state.

However, it does not really help for performance problems at all, as there is still the same amount of drawing. I would not try to use double buffering if you don't have a problem with flickering, as it requires more memory and flickering may be implicitly prevented by the system by similar or other means.

If you think drawing the background is too expensive, there are several things that you could look into:

• Do you scale the background image down while drawing? If so, create a downscaled version once and use this for clearing the background, reducing the drawing costs per iteration.

• Remember the "dirty" areas and just draw the portions of the background that were obscured. This will add some management overhead but reduce the number of pixels that need to be touched significantly

• Make the background the background image of the canvas DOM element and just clear the canvas to transparency in each iteration. If the canvas is very large, you could make this faster by remembering the "dirty" areas and just clearing them.

• Are you sure painting the background is the main cause of lag? Do you still have lag when you only repaint the background and do not do much else?