Is there documentation on how to use JS Interop MemoryView?

[groogiam]

Hello, this page references a MemoryView js object for marshaling data in javascript to a Span. I can't seem to find any documentation on how to utilize this class so large js arrays don't have to be copied? Thanks.

[maraf]

cc @pavelsavara

[pavelsavara]

If you pass Span<byte> to JSImport parameter, you will receive short-lived IMemoryView on the JavaScript side. It will be only available for the duration of the call. The other direction is not supported.

The API is this

runtime/src/mono/browser/runtime/dotnet.d.ts

Lines 661 to 679 in 794b0c2

	interface IMemoryView extends IDisposable {
	/**
	* copies elements from provided source to the wasm memory.
	* target has to have the elements of the same type as the underlying C# array.
	* same as TypedArray.set()
	*/
	set(source: TypedArray, targetOffset?: number): void;
	/**
	* copies elements from wasm memory to provided target.
	* target has to have the elements of the same type as the underlying C# array.
	*/
	copyTo(target: TypedArray, sourceOffset?: number): void;
	/**
	* same as TypedArray.slice()
	*/
	slice(start?: number, end?: number): TypedArray;
	get length(): number;
	get byteLength(): number;
	}

It forces you to copy from it or into in, because the C# Span<> could be on stack or something that moves in memory.

[groogiam]

@pavelsavara Thanks for the quick response. I am trying to pass a file blob from javascript to .NET. I was hoping there was some way to work with this data as a stream to avoid having a huge memory allocation. Is there anyway that you are aware of to accomplish this? I don't see anything specifically in the documentation so I'm guessing I will be stuck marshaling the underlying blob to a byte[] or base64 string. Thanks again for your help.

[pavelsavara]

You can also pass ArraySegment which will GC pin it and you will have long term buffer with IMemoryView interface on JS side. You have to dispose() it, when you are done.

You can also allocate via Marshal.AllocHGlobal and then pass it to JS as IntPtr.
Ideally allocating the buffer once and keep using it to transfer bytes on each chunk of your stream.

Then you can use localHeapViewU8 API to get wasm linear memory.

runtime/src/mono/browser/runtime/dotnet.d.ts

Lines 610 to 613 in 794b0c2

	/**
	* Returns a short term view of the WASM linear memory. Don't store the reference, don't use it after await.
	*/
	localHeapViewU8: () => Uint8Array;

Do it on each chunk, because WASM linear memory could grow, which invalidates this view.

I don't think it's possible/easy to use WASM linear memory as "Bring Your Own Buffer", exactly because the view could be invalidated by grow().

I wonder what's your specific use-case that our implementation of HTTP and WS are not good fit ? Please share more.

[groogiam]

My application supports an offline disconnected mode. This mode is implemented via a service worker and a shared worker. The shared worker spins up a .NET wasm instance and loads a subset of the server side code built for offline utilizing the ASP.NET core test host. The service worker than forwards any requests to the API to this worker which then sends them through to the test host running in wasm. It does this by translating the requests and re-executing on the client that created from the test host. For most cases this is just JSON based requests and not a problem. However we have file upload functionality that sends file data. Currently I'm sending this data as base64 which is going likely to cause performance issue if a large file were uploaded.

[maraf]

Sorry for adding a noise here, but that sounds super interesting and awesome!