Also, consider the following:
I am working on a project where the WASM interface isn't Skia's interface. Instead, the interface is a wrapper.Ā I am looking at exposing a more simple interface.Ā Where the javascript doesn't need to know about things like SkPath, SkCanvas, SkBlendMode or SkImage.Ā I have a C++ library that will understand all those things, but the javascript layer doesn't need to know about them.
I know that this sort of interface is not what you are targeting.Ā Your goal of exposing all the primary components of Skia makes sense and should not stop, by any means.Ā Ā
Maybe it would help if I explained my use case in more detail.
The company I work for has a universal viewer application.Ā It can view (almost) any file format type.Ā From office documents to CAD drawings and raster blueprints.Ā Almost anything... In our current situation, we have native applications that use Skia for the task of rendering to the screen.Ā For our HTML client, we convert to SVG.Ā (not using your code, but ours)Ā Ā
We have found SVG to suck.Ā There are a lot of things it cannot do. And even more things it cannot do well. We spend an unreasonable amount of time trying to get SVG to do what we want it to.Ā Ā
Then came the question:Ā What if the HTML client could use the same rendering code base as the native clients?
Which lead to this foray into Skia-WASM town.Ā Our native applications have multiple layers.Ā The GUI layer has no knowledge of the rendering layer that uses Skia.Ā Because that isn't his job.Ā A lower "draw()" layer knows about that sort of stuff.Ā We are trying to come up with a similar set of layers in our WASM implementation. Where the javascript layer doesn't need to understand things like Skia.Ā Or file format reading.Ā Or whatever. It only knows the minimalist interface we expose to native clients.