Why is canvas 2d so slow?

For example, compare WebGL version to Canvas2d version here (scroll to bottom to change mode): http://pixijs.github.io/pixi-particles-editor

Here’s a WebGL demo with 10000 particles: http://pixijs.github.io/examples/#/demos/batch.js

And here’s a canvas 2d demo with only 1000 particles: http://fabricjs.com/particles

Canvas 2d is accelerated (right?) yet so slow. Libs like Pixi (which offer very similar APIs) are so much faster.

What prevent Canvas 2d from being as fast as WebGL libs like Pixi?

Maybe the Canvas 2d backend needs a more polygon approach, like Pixi?

When rendering a large number of small primitives to a 2D canvas, rendering performance is limited by the CPU. Because each primitive requires an individual API call. There is currently no way to batch 2d context draws (except for paths, but they’s intrinsically slower than drawImage). A few years ago, I made a proposal to create a batch version of drawImage(), which I think could go a long way in accelerating sprite-based games and particle animations: https://wiki.whatwg.org/wiki/Canvas_Batch_drawImage . That proposal never went anywhere. Perhaps we should revive that effort. In blink/Chrome we do batching under the hood in skia’s GPU backend, which batches the GPU API calls, but we still suffer from lack of batching at the JS API call level. The feedback I got is that before moving forward with the spec, we should make an experimental implementation in at least one major browser to get some stats and prove there is significant performance to be gained in reducing the JS bindings and other per-call overhead.