[gb]

Clearing or filling large areas of <canvas> is cripplingly slow in every browser I've tried so far, so I'd assume it's that.

Hopefully that'll be worked on at some point in the not too distant future as it's one of the biggest problems I encounter when dealing with canvas at the moment.

[headbiznatch]

Thanks for the reply. It just seems counter-intuitive that canvas area should matter so much when the drawing logic is essentially the same. We are creating the same number of objects, just on a larger canvas and with different (X,Y) coordinates. Thus, the creation speed of the canvas itself (in memory, before flipping) should be roughly equivalent, right? The slow-down is simply from having to re-render the larger canvas? I'll dig more, of course, but quick insight from those in the know around here is always appreciated.

[weixiyen]

You just have to think lower level. There's the CPU to figure out what to draw, then there's the CPU (or GPU if using webgl) to actually draw what it figured out. More screen space increases rendering time b/c now you are drawing potentially 4x as much in the same timeframe.

Similarly, an image of 30kb takes more time to draw than an image of 10kb, even if they take up the same dimensions and space on the screen.

If you think this way, it's quite intuitive.

[headbiznatch]

True. I guess I'm just surprised by the magnitude of the effect. Thanks for the input.

[weixiyen]

it doesn't manifest itself until you put it in a loop and try to draw every 16 ms.

[headbiznatch]

Good point :)