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 just merged #134, which adds a new web handle type based on references to a JsValue. I opted to merge it now so we can migrate bikeshedding to a new thread.
Three strategies were proposed of having wasm-bindgen-based handles without using the data attribute ID hack:
Storing the internal idxu32 field that the JsValue is a wrapper around. While this approach is dependency free and compatible with the current WASM ABI, concerns were voiced that the new API introduced too many footguns, especially for smaller-scale use cases.
Storing the JsValue inline. This adds an optional dependency on wasm-bindgen and makes it so window handles can no longer be Copy.
Current: Store a pointer that is said to point to a JsValue through a reference. This, again, requires an optional dependency on wasm-bindgen, but makes the handles Copy.
Which strategy should we use to store web handles?
As I mentioned before, I'm not familiar with RWH, but option 1. seems to me to contain no more footguns then all the other handles.
Generally speaking, unlike other handles, these Web handles will only work with wasm-bindgen, so I think it makes sense to depend on wasm-bindgen. The data attribute ID is the only wasm-bindgen independent handle I can think of (or any other attribute).
JsValue is the least surprising option for both producers and consumers, and matched what people are already doing when they pass canvases to graphics APIs. The original goal of raw-window-handle was to make it easier to pass window handles between crates, so trying to match natural usage patterns seems like the pragmatic solution.
Using WasmAbi or pointers adds complexity and requires unsafe implementations, so it's easier for people to make mistakes. We could obviously document requirements but these may fail in subtle ways when the canvas is attempted to be used by the graphics API (e.g. use-after-free), so it adds extra friction for people getting started.
We already agreed that Copy is probably not necessary for window handles, so it shouldn't be a strong argument in favour of either option.
I just merged #134, which adds a new web handle type based on references to a
JsValue
. I opted to merge it now so we can migrate bikeshedding to a new thread.Three strategies were proposed of having
wasm-bindgen
-based handles without using the data attribute ID hack:idx
u32
field that theJsValue
is a wrapper around. While this approach is dependency free and compatible with the current WASM ABI, concerns were voiced that the new API introduced too many footguns, especially for smaller-scale use cases.JsValue
inline. This adds an optional dependency onwasm-bindgen
and makes it so window handles can no longer beCopy
.JsValue
through a reference. This, again, requires an optional dependency onwasm-bindgen
, but makes the handlesCopy
.Which strategy should we use to store web handles?
cc @madsmtm @grovesNL @daxpedda
The text was updated successfully, but these errors were encountered: