Run in browser using WASM and WebGPU.

[mateli]

Is your feature request related to a problem? Please describe.

There is currently no good way to run a C# application in a browser. This with the exception of solutions that run game engines in the browser that are scriptable by C# such as godot and unity.

These are the possible solutions:

• Run a DotNet implementation in the browser. This is what blazor wasm does and it is notoriously inefficient. This is already at least experimentally a possibility but not a preferred option for performance reasons.
• Compile C# to JS/WASM/WebGPU. While there are some incomplete solution for this it doesn't look very promising. Although RemObjects C# compiler does support a wasm backend this is a commercial compiler and may not be suitable for Avalonia.
• Compile CIL to JS/WASM/WebGPU. This is what most Java libraries does such as libGDX, TeaVM and Bytecoder. This is a better option in my mind than compiling C# to wasm as it doesn't require parsing source code and would support all .NET languages.
• Compile CIL to C/C++ and then compile with emscripten. Might also be an option especially as it makes SDL and other C/C++ libraries accessible.
• Thin client. Don't run C#/dotnet in the browser. Instead use the thin client paradigm where the server renders and encodes a video stream for the client to display similar to RDP and other protocol. This has the advantage of working very well on weak clients by borrowing server cpu/gpu capacity. The client can be written in C/C++ and compiled with emscripten. Bonus with this is that it is rather easy to implement but with the negative impact being that client side WebGPU isn't utilized.
• Thick client. Similar to thin client but push rendering to the server. Send over a binary tag stream for a scene graph with user interface primitives. The tag stream could be similar to HTML and AXAML but binary and compact to save on bandwidth. Then the client change interaction notification back to the server and the server sends update commands that modifies objects based on tags or otherwise modifies the scene graph. This can take full advantage of WebGPU and as it per design to not use any client side scripting it will not perform more processing than necessary the client. All features that web developers normally do by custom scripting should instead be standardized so that that speed can be gained by optimizing the web client part of this. In design this is similar to X11.

Describe the solution you'd like

I think that my preference is to have both a thin and a thick client as they both are optimal for their respective use cases. A thin client similar to RDP/VNC is optimal when the clients are weak and the server has lots of power and the additional advantage that it can fit right into the existing pipeline (using the existing Avalonia renderer off screen and sending the output over the network). A thick client uses less bandwidth, have lower latency and demands less from the server which is useful whenever the client can handle it.

I also think that both of these are simpler than getting C# code running in the browser. Also if both options are standardized well enough they can be used not only in other dotnet solutions but independent on server side language. The thick client I described is a bit like taking HTML, make it storage/bandwidth efficient, extending it with tags and attributes until no JavaScript is needed and finally make the DOM remotely updateable using WebSockets/WebChannels (SignalR?).

Describe alternatives you've considered

No response

Additional context

No response

[thevortexcloud]

C# such as godot and unity.

There is a godot backend for Avalonia.

https://github.com/MrJul/Estragonia

thin client similar to RDP/VNC is optimal

Avalonia actually has a VNC backend already. Some people are using it. Not entirely sure what for. It is however not particularly well documented and most people don't know it exists.

https://www.nuget.org/packages/Avalonia.Headless.Vnc/

Avalonia's only real requirements for a new backend is the ability to draw pixels somewhere and the ability to get input.

[maxkatz6]

There is currently no good way to run a C# application in a browser

I don't understand what's this issue is about.
There is a way to run C# in browser, and that's using WASM runtime. There are at least two supported options - Mono WASM (official and stable), and NativeAOT WASM (experimental).

Any other approach is a no-go. We are not going to compile C# into JS.
Or we are not going to run server and render each and single frame sending from the server to the client. This approach would work, of course, and as mentioned above Avalonia.Headless.Vnc is a proof-of-concept Avalonia backend that works in a similar way. But you must have very specific use cases to need this.

WebGPU

Now, WebGPU is a valid feature proposal.
Right now, Avalonia uses WebGL 1/2 or software rendering in Browser.
WebGPU support might bring us some performance benefits, and not only on Browser - it can be compatible with desktop and mobile APIs as well, due to being just a spec implementable even outside of browser.
Unfortunately, we need to get managed SkiaSharp supporting WebGPU first, since native Skia part seems to support it already.

[mateli]

Running C# in the browser with efficiency requires two things.

Those are compilation to WASM and integration with browser API:s such as WebGPU as well as including all the JavaScript glue code that is currently needed for such integrations.

Mono-wasm has not been updated in 7 years, is there a fork that is up to date with current wasm standards and browser API:s. It could be a way to go if it could be updated to include that.

NativeAOT might become a viable option at some point but it is very far from having the features needed.

Godot is nice for game programming but it is not an application programming plat

As for compilation to JS they are only mentioned because there are Java tools that goes that route and some of them are quite useful. Although compiling to JS do not imply that all browser API:s are supported so porting one of the Java compilers to DotNet may not provide a complete solution either.

Avalonia.Headless.Vnc on the other hand may be the closest to a viable solution when pared to a VNC client running in the browser so that is something that I will dig into.

As for a Thick client if I implement it I would probably want to go as high level as possible and replace skia on the Avalonia/server side with a layer that produce a binary scene graph, client side I probably go for C and SDL for rendering. As such there will be no wrapping of API:s for C# as a WebSockets or WebChannels will be the communication layer between C and C#.