[Experiment] Running Avalonia Browser on NativeAOT-LLVM

[maxkatz6]

Intro

While Mono provides stable support for WebAssembly in Avalonia, we were planning to investigate NativeAOT-LLVM for a long time. Recently several JSImport/JSExport related changes were backported to NativeAOT-LLVM branch, making it much easier to reuse the same Browser backend code (literally zero code changes, but with nuances).

After dealing with all the issues, refactoring part of SkiaSharp/HarfBuzzSharp, and doing it again but differently, I was able to get it running really well. As a surprise, even WebGL works (at least after SkiaSharp refactoring).

Biggest differences in app experience, comparing to Mono runtime, are:

• Much faster startup time. On a hello world app it's nearly instant, I would say excellent for a browser. ControlCatalog is poorly optimized on our side, but even then, it starts pretty quick.
• Much bigger bundle size. LLVM version is near 95mb, Mono AOT is near 50, Mono without AOT is just about 25. Unzipped and uncompressed both. Note, I used default build parameters for the most part. Excluding debug information from the build creates 40mb bundle for NativeAOT-LLVM.
• Performance difference is hard to tell. While some heavy pages are opening slightly faster, it's hard to get numbers, as we don't have any e2e benchmarks that can be run in browser.

Pending issues

NativeAOT-LLVM:

• [NativeAOT-LLVM] Delegates marshalling is broken in some scenarios dotnet/runtimelab#2624
  This issue makes it impossible to use most of SkiaSharp/HarfBuzzSharp as is. But luckily it's possible to migrate SkiaSharp to use function pointers. Just need to get it completed and merged.
• [NativeAOT-LLVM] DotnetJS JSExport fails, when function was defined in a Browser class library  dotnet/runtimelab#2626
  Worked around that by not using JSExport at all. It also required me to downgrade to 11.1 Avalonia branch, as that's the only branch that works without JSExport and without too many changes. Hopefully it can be fixed on NativeAOT-LLVM side.
• [NativeAOT-LLVM] DotnetJS Minor incompatibilities with WASM SDK on Mono runtime dotnet/runtimelab#2627
  Nothing fatal, but makes it harder to share code between runtimes.
• [NativeAOT-LLVM] DotnetJS exception on marshalled c#-objects finalizer call dotnet/runtimelab#2625
  Not fatal, ignored for now. Console is red though.
• No threading support as it seems yet. Simple new Thread().Start() fails with PlatformNotSupportedException. Haven't investigated it too deep, so no issue. But we generally want to have threading support, so it's possible to run Render and Dispatcher on two separated threads.

SkiaSharp:

• Function pointers and LibraryImport mono/SkiaSharp#2917

Other relevant issues:

• [NativeAOT LLVM] Support dotnet.js dotnet/runtimelab#2434
  Not everything is required for Avalonia, but helps with overall experience.
• [mono][wasm] wasm interop tracking dotnet/runtime#95084
  I was getting annoying errors running SkiaSharp with function pointers on Mono, like it's not possible to use them inside DllImport. But it was supposed to be fixed in .NET 9 already and I wasn't able to prepare minimal repro without Avalonia. For now fixed by using "void*" in DllImports.

How to test

I have built ControlCatalog with three different configurations.
NativeAOT-LLVM: llvm.zip
Mono, default: mono.zip
Mono, AOT: mono-aot.zip

But you also can clone Avalonia and checkout nativeaot-llvm-experiment branch.
ControlCatalog.Browser then can be built via:

dotnet publish -p:UseNativeAotLllvm=false -r browser-wasm
dotnet publish -p:UseNativeAotLllvm=true -r browser-wasm

Note, it requires locally built SkiaSharp and HarfBuzzSharp, as my changes weren't yet merged.

cc @yowl @SingleAccretion @maraf and @mattleibow

[maxkatz6]

Some video running both Mono and NAOT-LLVM versions as well

browser.mp4

[hez2010]

Can you try adding /p:NativeDebugSymbols=false /p:StackTraceSupport=false while publishing the app?
Currently NAOT-LLVM will embed all debug symbols into the binary which can contribute a lot of binary size.

[hez2010]

Update: by applying /p:NativeDebugSymbols=false /p:StackTraceSupport=false, it yields a bundle size for about 40.4mb (all pdb and xml documents removed), which is a lot smaller than Mono AOT.

[AmSmart]

Wow, Native AOT is super impressive

[hez2010]

Here is the one built with debug symbols stripped:
ControlCatalog.Browser.zip

And with brotli compression, the total size becomes smaller than 10mb!

[JaggerJo]

Here is the one built with debug symbols stripped:

ControlCatalog.Browser.zip

And with brotli compression, the total size becomes smaller than 10mb!

That's quite impressive!