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
Up until preview6, the blazor filereader Wasm library used unmarshalled calls to communicate the file chunks from js to .net. This is no longer the case due to a breaking change in blazor(mono?) that broke the implementation. Might be something as simple as a name change in the API, have not investigated thoroughly.
Main motivation of reintroducing this thing is speed (~30% faster) and general memory / cpu usage (not really benchmarked though current marshaled memory usage should at minimum the be 2.4 * buffer size compared to unmarshalled)
First issue is how to re-implement the method.
The original implementation passed a reference to a byte array to js in the first call. Current implementations doing about the same thing (ex http message handler in blazor) rather have a call originating from js to allocate and get a reference to that array, which could be considered being the reference implementation.
Second issue, how to enable usage of the method..
As there is still no WASM target for libraries, an initialization option has to be added that enables referencing MonoWebAssemblyJSRuntime.InvokeUnmarshalled<...>. I'm a little bit unhappy about making end-users do that this as it makes setup quite complex. Might be possible with a simple boolean option but that would cost a lot in reflection instead.
The text was updated successfully, but these errors were encountered:
After taking the time to read Blazor's http.ts and WebAssemblyHttpMessageHandler.cs thoroughly, I think there is a big possibility to avoid using MonoWebAssemblyJSRuntime.InvokeUnmarshalled altogether, this is good news. For library users, a boolean should be enough (platform detection is thus delegated to the setup procedure, something like options.UseWasmSharedBuffer = true).
The strategy should be to re-introduce a Task-queue of callbacks for passing back the array (instead of the very comfortable await InvokeAsync() -> result, use await InvokeAsync() -> void and TaskCompletionSource just like dispatchResponse calls WebAssemblyHttpMessageHandler.ReceiveResponse.
While WebAssemblyHttpMessageHandleris using InvokeUnmarshalled to pass a byte array to js, in my case there is no need to pass anything, only the response is interesting, thus referencing MonoWebAssemblyJSRuntime can be avoided.
Tewr
changed the title
Reintroduce unmarshalled interop
[WASM] Reintroduce shared memory buffer
Aug 2, 2019
Up until preview6, the blazor filereader Wasm library used unmarshalled calls to communicate the file chunks from js to .net. This is no longer the case due to a breaking change in blazor(mono?) that broke the implementation. Might be something as simple as a name change in the API, have not investigated thoroughly.
Main motivation of reintroducing this thing is speed (~30% faster) and general memory / cpu usage (not really benchmarked though current marshaled memory usage should at minimum the be 2.4 * buffer size compared to unmarshalled)
First issue is how to re-implement the method.
The original implementation passed a reference to a byte array to js in the first call. Current implementations doing about the same thing (ex http message handler in blazor) rather have a call originating from js to allocate and get a reference to that array, which could be considered being the reference implementation.
Second issue, how to enable usage of the method..
As there is still no WASM target for libraries, an initialization option has to be added that enables referencing
MonoWebAssemblyJSRuntime.InvokeUnmarshalled<...>
. I'm a little bit unhappy about making end-users do that this as it makes setup quite complex. Might be possible with a simple boolean option but that would cost a lot in reflection instead.The text was updated successfully, but these errors were encountered: