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.
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.
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...
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?
Something that could either be called laziness or difficulty, depending on your perspective.