On the Amiga, you didn't go the stupid way around and represent your object as a series of text path strings which need to be parsed into objects and then finally displayed for each frame.
You can get your Amiga performance with canvas; and you can get way better with WebGL. This is just a case of wrong-tool-for-wrong-job.
Do you realize that in Canvas colors are represented as a "series of text strings" that need to be parsed?
Did you know that drawing paths requires a ton of pretty expensive Javascript calls or alternatively passing "a series of text strings"? Maybe the string way is actually faster, I haven't tested it because it isn't supported everywhere.
Were you aware that vector rendering is not usually done on GPUs, mainly because of the high overhead of state changes when using a graphics API, especially one like WebGL?
I guess you could do all your rendering in software in Javascript (which for these purposes is nowhere close to what you can get with C/C++) to a byte buffer and then do the final transfer to Canvas. Even in that case, you might be surprised how much overhead that final transfer has...
> Were you aware that vector rendering is not usually done on GPUs, mainly because of the high overhead of state changes when using a graphics API, especially one like WebGL?
But it's actually worse than that, isn't it? It's not only that I can't render a complex SVG path on the GPU, but I can't even apply a GPU accelerated transform on existing child nodes of an SVG.
Why is it that <div> can get a GPU-accelerated transform but <g> can't?
You can get your Amiga performance with canvas; and you can get way better with WebGL. This is just a case of wrong-tool-for-wrong-job.