Hi amaso83, this is not a simple issue and Gio is probably better equipped to answer but I will give it a shot.

There are multiple factors here that make the answer very dependent on what you are trying to do, this is why we included the ability to select which rendering mode to use for individual layers.

WADE has alot of optimizations for canvas mode making it pretty good at most tasks, having said that, if you throw a huge number of pixels at the hardware, you will likely have better luck with WebGL

This does not necessarily mean WebGL is always faster. Draw calls in GL are expensive, if you are drawing a large number of small sprites, the performance could be slower than the canvas. With every draw call

WebGL has to do many calculations, setting things up on the GPU which is slow. Modern GPU's are designed to process a few huge batches of triangles at a time, not thousands of smaller batches as this greatly increases the overhead.

I realise the above is a little confusing so I have summarized below some basic rules.

* WebGL is still not fully compatible with many devices. WADE will automatically revert to canvas if WebGL is not available, but this is something to keep in mind, your app ideally should not

be dependent on the possible performance boost WebGL can offer.

* For objects that don't move, a static background for example, use canvas. After the initial draw, so long as you do not move the background, it will not have to be redrawn to canvas.

* If you have a small number of very large images that are moving often, try using WebGL to crunch those pixels faster, it could help quite alot.

* Test on as many real devices as you can, there are so many possible situations that testing your application really is the best way.

I hope Gio responds to this post soon, I will make sure he see's it as he has a great deal of experience with Graphics Programming.

You are asking a VERY tricky question there... foxcode's answer is essentially correct, I don't know if adding more details to it is going to help or confuse you, as it gets quite technical :) Here it goes anyway:

WebGL is always hardware accelerated so, in general, it tends to be faster than canvas (which may or may not be hardware accelerated, and when you're doing anything remotely complex with it, it most certainly isn't). However:

1. Some things are always done in canvas behind the scene. Drawing text for example, especially with effects - even if you are in WebGL mode, it gets drawn to a canvas, and this canvas is then used as a texture for the WebGL renderer. This texture is cached (so as long as the text doesn't change the texture isn't recreated), but if you have a layer with lots of text that changes very often, canvas is going to be faster. The same is true for any sort of vector graphics.
    
2. In canvas mode, you draw to the canvas directly. This allows WADE to do some optimizations such as only redrawing areas of the screen that haven't changed since the last frame. In contrast, in WebGL mode, you draw to a back buffer, which is then displayed to the screen.The contents of the back-buffer aren't guaranteed to be preserved from one frame to the next, so this type of optimizations cannot be done. Well technically there is a way to do it, but it would have a negative impact in those cases where many objects move on the screen, so it isn't a good idea. To make an example: if you have a scene with many different objects, but only a few pixels change from one frame to the next, canvas may be faster.

Also consider that there is scope for improving the performance of our WebGL renderer, we do have some further optimizations planned.

TL;DR:  Which one is faster does depend on your particular scenario, though WebGL is generally better. But you can use both canvas and WebGL together (on different layers), so it may be worth trying to groups all vector graphics objects on one layer for example and set that layer to canvas. This isn't always an option, and whether it actually speeds things up significantly, again, depends on what exactly you are doing.