code red art (Oct 10 2023 at 17:06): code red art (Oct 10 2023 at 17:06):I am trying to figure out bindings for an immediate mode gui api (eg: imgui), and it uses a lot of repr(C) abi stable types. Some simple examples are glam types like Vec2, Vec3, Vec4, Rect, Rgba etc..
If the guest queries a Rect of the current viewport, the host fn can take a guest provided pointer (i32), and write to it an repr C Rect struct using memory from Caller arg. I assume the bottleneck here is getting memory from caller as it needs to look up "memory" from exports every single time this fn is called.
I see that component model finally released experimental support (yay), which supports Record types. From what i remember, records from bindings will be generated as native structs. But idk if they will be directly written to wasm's memory when host passes a type to guest, or if there is some other background bookkeeping going on which will be a bottleneck now.
I was hoping someone could tell me what the ideal way of creating ffi bindings would be, so that plugins can call into my immediate mode gui api with minimal performance impact (as this calls will happen every frame, for tens of plugins).
code red art (Oct 10 2023 at 17:22):a component model Rect would be like
record rect {
top_left_x: f32,
top_left_y: f32,
width: f32,
height: f32,
}
When using bindings generation transferring a value like rect happens automatically and the bindings take care of the abi details. In that sense yes they will write to memory for you.
Bindings generation does not currently support a "bring your own types" mode however so you would need to write a conversion from the component types to your preexisting types. LLVM is likely to optimize this away if they have the same structure, and if you really want you can lay out the component struct the same way and unsafely transmute the pointer to avoid conversion
Notification Bot (Oct 10 2023 at 18:41):code red art has marked this topic as resolved.
Last updated: Dec 23 2024 at 14:03 UTC