For Blazor Canvas rendering, is Unmarshalled Interop possible for the draw calls?

[RChrisCoble]

Unmarshalled interop is one of the noted features in .Net 6 for Webassembly.
https://github.com/dotnet/runtime/issues/43767

Avoiding the JS Interop layer would greatly speed up rendering, considering every single method and property call needs to traverse this boundary. Is this possible for .Net 6 now that you have Blazor compiling again?

Thanks.

[charlesroddie]

The linked tracking issue is related: User Story: Developers can easily use NuGets with native libraries to build fast wasm projects .

[RChrisCoble]

I'm familiar with this feature, as back when the .Net 6 backlog was being planned I requested to Dan Roth we have this ability in Blazor, specifically to use SkiaSharp in client browsers for rendering. This was months before Maui.Graphics became a repo and I was looking for a cross platform 2D rendering API.

That being said, that feature assumes SkiaSharp is being used in this repo to render on Blazor Webassembly, which it doesn't appear to be at present. The Blazor bindings only have Canvas and WebGL.

So, unless this repo plans to add SkiaSharp support to Blazor, I'm not sure this applies.

[RChrisCoble]

Or @charlesroddie is this your way of saying this repo will provide SkiaSharp rendering support in Blazor WebAssembly with the express intent of delivering a high performance rendering implementation that allows bypass of the JS/Interop layer, which isn't possible with Canvas/WebGL?

If this is the case, I'm curious if this will require people to AOT compile their code for that Unmarshalled Interop to work.

[charlesroddie]

I am just an observer of this repo. It should give cross-platform 2D rendering with less overhead than SkiaSharp and that is particularly important for web where a few extra MB is a big deal. [Although I see that Skia is used in a few browsers - maybe then SkiaSharp doesn't involve a big download? Will check.] I see this as the key piece to take our dekstop+mobile app to browsers. I don't think Maui.Graphics -> SkiaSharp -> Web makes any sense; it needs to be Maui.Graphics -> WebGL.

I expect that deploying Maui.Graphics for web will have similar issues to SkiaSharp for web, and both will require native dlls which the linked issues is about. Definitely AOT compilation will be essential for deploying to end-users. So in the end they will get WASM with WebGL.

This issue you posted is important in the long run, but getting the current code to display something on web must be the first step and perf questions come later.

[charlesroddie]

Rust has some success with 2D wasm graphics at the moment: https://github.com/femtovg/femtovg (demo website) .

Regarding the unmarshalled interop in this issue, while an improvement, it will involve javascript which is not ideal, and interface types in wasm may be needed to avoid that.

[Kation]

Any progress?