You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to build a plugin system with wasmtime for my app. And i want plugins (guests) to use skia for drawing UI and other stuff.
I can think of two ways to do this:
just let guests compile skia-safe (and static linking skia) to wasm and I will provide them with opengl function bindings, which the guest's skia will use to draw stuff.
guests will use skia-safe but without statically linking the actual skia library. When i load the wasm guest, i will provide the C extern functions (like a dll) at runtime.
statically linking skia into wasm
The below section shows issues with compiling skia-safe (statically) to wasm.
compiling Skia to wasm
Ideally, plugins would use their own favorite 2D api, and i will only give them opengl fn pointers, which they can call at the end with flushing. But https://github.com//discussions/711 -> skia crate cannot compile to wasm32-wasi target. I tried to fix that, but there are two different problems
1. By default it enables and builds skia pdf feature -> which builds turbo jpeg or png libs -> which use setjmp in their code -> https://github.com/WebAssembly/wasi-libc/issues/432 but wasi doesn't support setjmp yet :(.
4. If i try to use system libs (and avoid compiling jpg/png libs), it still has a bunch of missing header errors like `` in https://github.com/google/skia/blob/main/src/base/SkContainers.cpp#L16 or `` in https://github.com/google/skia/blob/main/src/base/SkSemaphore.cpp#L13 . apparently, for some ungodly reason, `SK_BUILD_FOR_MAC` define is true when i try to compile for wasi. After messing around for a few hours, i gave up on trying to build it on wasi. My cpp is already terrible, but dealing with build systems makes me 😭
dynamically linking skia-safe
So, the second best option is letting the plugins use the skia crate, but leaving the extern "C" functions of skia as dynamic linkable. So, we (the plugin host) can provide them when we load the plugin.
This has the advantage that compile times will be super fast for guests (as you are not downloading/linking the skia library).
At the moment, skia-safe will automatically build and try to link skia statically. Is it possible to add a feature that allows dynamic linking of skia extern fns?. skip the whole build step (using pre-generated bindings maybe?) of c/cpp code, so that i don't have to worry about c/cpp when compiling to wasi target.
If you can do that part, i can write a separate crate where i bind all the skia ffi functions into wasmtime, which will (probably) be useful to others who want to enable a "skia fiddle" sort of thing on desktops.
The text was updated successfully, but these errors were encountered:
I am trying to build a plugin system with wasmtime for my app. And i want plugins (guests) to use skia for drawing UI and other stuff.
I can think of two ways to do this:
statically linking skia into wasm
The below section shows issues with compiling skia-safe (statically) to wasm.
compiling Skia to wasm
Ideally, plugins would use their own favorite 2D api, and i will only give them opengl fn pointers, which they can call at the end with flushing. But https://github.com//discussions/711 -> skia crate cannot compile to wasm32-wasi target. I tried to fix that, but there are two different problems 1. By default it enables and builds skia pdf feature -> which builds turbo jpeg or png libs -> which use setjmp in their code -> https://github.com/WebAssembly/wasi-libc/issues/432 but wasi doesn't support setjmp yet :(. 4. If i try to use system libs (and avoid compiling jpg/png libs), it still has a bunch of missing header errors like `` in https://github.com/google/skia/blob/main/src/base/SkContainers.cpp#L16 or `` in https://github.com/google/skia/blob/main/src/base/SkSemaphore.cpp#L13 . apparently, for some ungodly reason, `SK_BUILD_FOR_MAC` define is true when i try to compile for wasi. After messing around for a few hours, i gave up on trying to build it on wasi. My cpp is already terrible, but dealing with build systems makes me 😭dynamically linking skia-safe
So, the second best option is letting the plugins use the skia crate, but leaving the
extern "C"
functions of skia as dynamic linkable. So, we (the plugin host) can provide them when we load the plugin.This has the advantage that compile times will be super fast for guests (as you are not downloading/linking the skia library).
At the moment, skia-safe will automatically build and try to link skia statically. Is it possible to add a feature that allows dynamic linking of skia extern fns?. skip the whole build step (using pre-generated bindings maybe?) of c/cpp code, so that i don't have to worry about c/cpp when compiling to wasi target.
If you can do that part, i can write a separate crate where i bind all the skia ffi functions into wasmtime, which will (probably) be useful to others who want to enable a "skia fiddle" sort of thing on desktops.
The text was updated successfully, but these errors were encountered: