You think using getImageData and putImageData is more performant that drawImage(canvas, 0, 0) ?
BTW i'm not sure it will works for combining images together with special composite operation.
http://jsperf.com/canvas-drawimage-vs-putimagedata/11
also read this about imageData caching and explanations of the different opts. loop unrolling helps a bit, forget the typed array stuff for now, it wont work anywhere for some time.
http://hacks.mozilla.org/2011/12/faster-canvas-pixel-manipul...
But I don't use hidden canvases, just .drawImage each visible tile of terrain into the middle canvas each frame. I'll try to draw to hidden canvas, and see the difference, thanks for suggestion.
When I draw everything moving to off screen canvas, and then drawImage this off screen canvas into visible canvas, I get 48% of time in draw function, and ~35 fps.
It is indeed faster to draw everything to off screen canvas, than to on screen one (when I commented out copying off screen canvas to on screen canvas, and left only drawing sprites and tiles to off screen canvas - I got steady 60 fps, but obviously nothing is visible then :)). And copying whole canvas to the visible one is still slower, than drawing the sprites and tiles on the visible canvas in the first place.
But thanks for ideas.
My fastest code:
for (var y=y1; y>=y0; --y) {
var resultY = (0.5+
(level.topLeft.y - camera.position.y + camera.screen.height / 2 +
level.cellHeight + y * level.cellHeight-level.cellHeight)
)|0; // fast clip to int
for (var x=x1; x>=x0; --x) {
var tileImageNo = level.layers[z].cells.valueAt([x, y])-1;
if (tileImageNo==null || tileImageNo<=0) {
//nothing to do
} else {
ctxOnScreenCanvas.drawImage(
tiles[tileImageNo],
(0.5+
(level.topLeft.x - camera.position.x + camera.screen.width / 2 +
level.cellWidth + x * level.cellWidth- level.cellWidth)
)|0, // fast clip to int
resultY
);
}
}
}
I could try drawing to off screen canvas only when player moves out off current off screen canvas, but that will trade small delay each turn into big delay every N turns, and that's even worse. But I'll try that.
EDIT: cuting out not important code.
- You have a background layer, lets just say it's a blue background - A middle layer, lets say clouds that move as you move to the right - And a tile layer, which draws the sprites, and the tiles of the maps
For the tile layer, we can break it down into two separate groups, animated sprites, and static sprites.
The static sprites, can be drawn to the offscreen canvas, and you get the imageData from that one time, and then push that data to the screen there after. Then the animated sprites will just be drawn to the on screen canvas every time. http://imgur.com/n6RFF The stuff that should be drawn to the offscreen canvas, then grab the image data has gray around it, and the animated sprites are in the green.
So for drawing the tiles of the map we only have to loop through the tile data, one time, and after that if the imgData remains valid (a separate flag) we can just push that imgData to the screen.
This would also allow drawing section of the screens on the offscreen canvas in chunks, and storing that draw to just be pushed to the screen at appropriate times.
I don't know if I explained it very well, I could probably through together a crappy little demo if you'd like.
they use multiple canvas layers. from working a lot with canvas lately, the fastest was to draw to canvas is not to draw to it :). if you have a scrolling bg that is static, you can just use a bg image sprite and scroll it via CSS/js. anything that can be done with a sprite should probably be done with one.
even for collisions etc, you're best off doing all the logic for your shapes and manipulating a DOM element (or even a mini-canvas) than re-rendering an entire huge canvas.