This is a native dependency where that's compiling skia itself to wasm. The native dependency should be able to be faster by a wide margin by taking advantage of hardware acceleration but it's not obvious if it does (similarly skia compiled to wasm must be much slower than using the proper canvas API in the browser)

Why is wasm necessarily slower than the browser if the browser is already implementing canvas via skia? Just the hardware acceleration? Does that mean only gpu access or something more?

Not that that would make much sense. I’ve not been very successful at understanding what kind of problem canvaskit is trying to solve

What I am trying to do is the same as it was more than a year ago (https://news.ycombinator.com/item?id=20339574): A tile based, web based view with prerendered image tiles from the server and on the fly rendered tiles on the client. Ideally the client side rendering is super fast, whether that means gpu is enough or multi threaded cpu I don’t know yet

So what I understand so far is that I can’t have anything multithreaded (yet?) in the web client and probably native canvas is the most performant. Even canvaskit with webgl won’t reach that performance (not sure here)

Otoh canvaskit could possibly be used in other browsers if they don’t natively implement canvas via skia itself to minimize render diffs

And lastly this project here could be the backend renderer instead of either headless browser via canvas api (hacky) or canvaskit in node (slow because cpu only)

But none of these offer and kind of performance increase over native canvas which is limited to single thread because of spectre and meltdown

Yeah, Skia itself has multiple backends, including CPU and GPU implementations. The wasm one must use the CPU path, where Skia in your browser can use a CPU or GPU path based on whatever is fastest. So already wasm is necessarily equal-or-slower.

Wasm also does have some overhead too; some of that will get better with upcoming changes; at least wasm-SIMD support and threads are both only available in some environments.

But don't get me wrong, I'm certainly not suggesting the skia-wasm project is pointless, there's just trade-offs here.

What are the uses of skia wasm then?

So far I’ve mostly heard about porting apps that require native skia to the web. But that wouldn’t explain why google spent all that effort building a canvas compatible api and didn’t just stick to the skia api

I was hoping that skia would be more efficient in this tiling context where rendering tile images and putting them together in the final view isn’t that great with browser canvas. But I realize now that lack of multithreaded tile rendering means it doesn’t matter much anyways whether image tiles can be copied to another image quickly or not

Now I have a feeling that webgl might be a necessary step for me to look at.

This project has been dormant for a year now and I have to start again. Not an easy area to navigate with all those different and not necessarily comparable solutions

Last I played around with canvaskit I found the performance in the browser to be better than native canvas for certain things but worse for most. Why that is or if this follows any rules I don’t know. Perhaps I’m also mistaken

> Why is wasm necessarily slower

Usually wasm is twice slower than native code: https://www.usenix.org/conference/atc19/presentation/jangda

WebAssembly is essentially a bytecode that needs to be JITted before running. That's pretty much the same situation as with Java, you may have comparable performance but usually comparable Java code runs slower that native.