The slow downs usually comes from abstraction layers. If you just use the api it will be fast. But if you create 1 million new objects and have 2 million function calls in excess on every frame it will be slow. Eg. If you dont like imperative style it will be slow. A compilation step and a bunch of optimization runs could make anything fast thought.

It really is not. If you want to set the current color you have to assemble a css color string from your color values. There is no way to make this fast. When you ship production 2D games using canvas, stuff like this shows up in your profiles and there's no way to optimize it out other than not using canvas. (Many people switch to using WebGL to do 2D themselves for this reason - it's faster.)

If setting the color is the bottleneck you can for example paint all red shapes, then paint the blue shapes, etc, instead of setting the color for every shape. You can also use different canvases . Offscreen and worker canvases is in experimental which enables further optimizations. 2d canvas has some very expensive calls, the trick is to only call them once, not for each object, not even for each frame. If you have 3d objects eg. Z-index its better to use 3d canvas. Yes 2d canvas is slow, but 2d scenes should be able to be optimized by only painting stuff once, then translate, rotate, reset and reuse. Set some upper limit of moving parts on the screen, then use pooling and caching. Put all canvas calls in the same file/ function then it will be easy to see what code can be removed/re-ordered eg. set the color once, not 1000 times after each other.

"HTML canvas ... generally bad API"

Agree on that. But this is not about Canvas::Graphics.

The original post appeared to be suggesting just using HTML Canvas (since it's backed by Skia). Was it suggesting something else?