Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have just recently started some experiments with game development in Javascript/HTML5, and so far it has been going pretty well. I have a simple test scene running with some basic input handling, and a hundred-ish drawImage() calls with a few transforms. This all runs great on Chrome, but unfortunately, it already chugs on Firefox. I am using a very large canvas ( 1920 x 1080 ), but it doesn't seem like I should be hitting my limit already. So on that note, I was hoping to ask a few questions:

1) What exactly is done on the CPU vs. the GPU in terms of canvas and drawImage()? I'm afraid the answer is probably "it depends on the browser", but can anybody give me some rules of thumb? I naively imagined that each drawImage call results in a textured quad on the GPU with the canvas effectively being a render target, but I'm wondering if I'm pretty far off base there...

2) I have seen posts here and there with people saying not to use the translate(), rotate(), scale() functions when drawing on the canvas. Am I adding a lot of overhead just by adding a translate() call, as opposed to passing in the x,y to drawImage()? Some people suggest using "transate3d", etc., which are CSS properties, but I'm not sure how to use them within a scene. Can they be used for animated sprites within a single canvas?

3) I have also seen a lot of posts with people mentioning that pre-building canvases and then re-using them is a lot faster than issuing all the individual draw calls again. I am guessing that my background should definitely be pre-built into a canvas, but how far should I take this? Should I maintain an individual canvas for each sprite, to cache all static image data when not animating?

Thank you much for your advice!

share|improve this question
You should check this article if you didn't : Improving Canvas performance – Whiskas Sep 18 '12 at 1:23

If you are redrawing the entire canvas several times a second this can be slow on any browser (had the same problem when testing on the g/f's low spec laptop).

Could you look into only redrawing the areas you need, and therefore reducing the amount of canvas that is redrawn in each frame?

This is how I got the greatest performance increase in my small demo app.

share|improve this answer
I'd like to try only redrawing certain areas, but I am unsure how to accomplish it for my desired effect. My game is designed to have a large scrolling world in X & Y ( to-down view ), with a number of "entity" sprites moving on top of that world. The world BG is entirely static, but since it can scroll, it seems like I still need to redraw it to the canvas each frame. I have tried drawing the BG into a large offscreen canvas and then drawing a subsection into the main one, but it doesn't seem to get me much performance gain. Are there better ways of accomplishing the scrolling BG effect? – jujumbura Sep 18 '12 at 15:15
For my particular example the background was static so I got a big benefit by not needing to redraw each frame (I just did the sprites). Afraid I'm not sure how best to cater for a scrolling BG :( – dougajmcdonald Sep 18 '12 at 15:35
think about using layered canvases, and you might balance graphic load by updating some of them less often, and also win time only clear your sprites on the main canvas instead of clearing whole canvas. – GameAlchemist Dec 10 '12 at 0:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.