Do you draw to an offscreen canvas first?

[NokFrt]

Hi,

 

Do you draw your graphics to an offscreen canvas first, or do you draw everything directly to the main canvas?

 

On other platforms, it's usually much faster to draw everything to an offscreen buffer in an internal resolution and then draw and scale this buffer to a screen. But if I try to do this in HTML5 than the result is not good as I expected, especially in the Android stock browser, where it's much faster to draw everything directly.

 

Tomas

[Ezelia]

it really depend on what you are drawing.
if you are juste drawing something to an offscreen canvas, then copy that same thing to the mane canvas for each frame, you'll not notice big improvement it any.
if you need to compose something from a set of images, for example a character with its clothes and properties, then it's better to compose it one in the offscreen canvas then copy the whole character to the main canvas. (here you are reducing draw calls)

[rich]

Double-buffering is un-needed for canvas (it does it automatically) and adversely harms your performance.

[NokFrt]

it really depend on what you are drawing.

if you are juste drawing something to an offscreen canvas, then copy that same thing to the mane canvas for each frame, you'll not notice big improvement it any.

if you need to compose something from a set of images, for example a character with its clothes and properties, then it's better to compose it one in the offscreen canvas then copy the whole character to the main canvas. (here you are reducing draw calls)

 

Sure, it's better to prepare complex images in a buffer, but I've meant an offscreen buffer for a whole screen. You don't reduce draw calls like that but you reduce scaling. It should be better to draw everything in an internal resolution and then scale the whole image. But I'm not sure about that in HTML5. 

 

For example I have a canvas 960x480 but my internal resolution is 480x240, so every image draw I scale the image 2x.

[NokFrt]

Double-buffering is un-needed for canvas (it does it automatically) and adversely harms your performance.

 

Thanks, I didn't know that.

[Gio]

It really depends on the platform. In most cases it's a bad idea (like Rich says, it harms your performance, and it also ends up using more memory than what you would need).

 

In some cases however (for example in the awful android stock browser for android 4.0 to 4.2), it actually helps get around a few browser bugs. I think this is because swapping canvases  actually forces the browser to do a full redraw.

 

Another example where this could be useful, is in some mobile browsers (namely windows phone 8 and tizen) after your window loses visibility (someone calls the player while they're playing for example), then doing the double buffering thing for one frame forces the browser to do what it's supposed to do.

 

Also in older versions of Chromium, the screen would refresh periodically (60 times per second) even when you were in the middle of a draw, sometimes showing incomplete frames (this hasn't been the case for a good while now though), so double buffering was needed to get a decent visual quality.

 

We have the option to turn double buffering on and off in our framework, and we do so depending on the platform (but 90% of the times it's off).

 

Regarding your comment about scaling: there are two types of "drawing" in html5. There is the process of drawing stuff into your canvas, which may or may not be hardware accelerated, and then there is the actual drawing of the canvas onto the screen (this is where the scaling happens), which is entirely controlled by the browser and is almost always hardware-accelerated, and takes place (mostly) when the javascript engine is in an idle state, i.e. between frames. So you don't need to worry about that, the amount of work that is done for scaling your canvas should be the same in all sensible browsers.

[AshleyScirra]

We implemented a "low quality fullscreen scaling" option in Construct 2 recently. It draws to an offscreen canvas at lower resolution (e.g. 64x480) then stretches up the result to the full display (e.g. 1920x1080, but keeping aspect ratio). Many users report this significantly improves performance.

[rich]

Ashley - isn't that the same thing as having a "low res" canvas (i.e. 640x480) in the first place and just scaling it via CSS? Did you add this feature because otherwise it would have made a 1920x1080 sized canvas? (which I can imagine would be significantly slower than a 640x480 one!)

[AshleyScirra]

It's probably the same, but we get to control the sampling (point/linear). Maybe CSS supports that as well now, but some engines like CocoonJS don't let you specify canvas CSS anyway, so it works for that too. Using the full-size canvas is still the default, since the quality is much better for text, shaders, and downscaled sprites.