Remove dependency on Blazor for WebGL platform?

[dtaylorus]

What do you think of removing the dependency on Blazor for the WebGL platform?

It seems like the technical issues may have been solved in the sample project at https://github.com/RedMike/SdlWasmSample

[nkast]

That's interesting. I found a clean example here https://github.com/khalidabuhakmeh/HelloDotnetWasm/
This would give us a cleaner template for hosting a static stand alone web game.

At the moment I still support net6, which will be dropped after November which reach it's end of support.
Then we need to start moving to the new JS interop introduced in net7. I suppose it's a requirement for this new target.

But also, are we talking about dropping Blazor completely? At the end we can ignore the hosting environment, whether it's Blazor, WinForms, or SDL, and focus on writing the Game.
There are advanced scenarios that we haven't even start to to explore. Like visual Blazor components , easy integration with SignalR, etc. I guess it depends if we can build the Wasm library to target both without much overhead.

[dtaylorus]

Yes, for my purposes I would love to completely drop Blazor.

My priority is to have my game load fast, ideally as fast as games that use HTML5/Javascript frameworks, and the possibility of removing all that unused Blazor code and maybe even getting a build with full trimming sounds amazing.

Maybe the published build could even become small and light enough to create playable ads in C# to promote my game rather than having to rewrite the ads from scratch.

Much longer term I hope it will one day be possible to completely remove the dependency on Javascript in favor of WASI/WebGPU, so moving in the direction of fewer dependencies on Javascript and the browser environment makes sense to me for games, where it may not make sense for Blazor apps.

[nkast]

Here is a list of brotli compressed files in /_framework/ of the published Primitives3D sample,
It's ~3MB. What of those do you thing we can get trimmed out? Perhaps we compare it with the HelloDotnetWasm sample.
The removal of one library can have a cascading effect down on the core libraries, so it's hard to say what the gain might be.
Hopefully Trimming might get better, or we can find other ways to improve it.

I am currently excluding the Content readers in the ILLink.Descriptors.xml.
There might be a better way, with [DynamicDependency] we can mark Texture2D to preserve the Texture2DReader and it's members. This way we can trim lesser used types like a TextureCubeReader, and in in effect TextureCube itself, etc. That's just an early tough, we have to test it and explore edge cases. That property comes with a warning not to be used, I don't know why. Perhaps it's just unoptimized.

Also, I am currently excluding all the backend factories. That's why it brings in Framework.Media.wasm and Framework.Audio.wasm which I don't really use in the sample. Perhaps there's a way to remove those.

Directory of \XNAGameStudio\docs\wasm\Primitives3D_framework
839.751 dotnet.native.wasm.br
465.985 System.Private.CoreLib.wasm.br
248.840 icudt_CJK.dat.br
222.250 icudt_no_CJK.dat.br
221.999 dotnet.runtime.8.0.3.d2kvxvq3vc.js
143.983 icudt_EFIGS.dat.br
135.251 dotnet.native.8.0.3.low7p2m3bx.js
109.162 System.Text.Json.wasm.br
71.122 Microsoft.AspNetCore.Components.wasm.br
60.383 blazor.webassembly.js
52.931 Xna.Framework.Graphics.wasm.br
48.957 System.Text.RegularExpressions.wasm.br
44.210 MonoGame.Framework.wasm.br
35.845 dotnet.js
26.544 Xna.Framework.wasm.br
25.360 System.Private.Uri.wasm.br
25.169 Microsoft.AspNetCore.Components.WebAssembly.wasm.br
17.926 Xna.Framework.Content.wasm.br
16.995 Microsoft.Extensions.DependencyInjection.wasm.br
15.308 Microsoft.JSInterop.wasm.br
14.320 Microsoft.AspNetCore.Components.Web.wasm.br
13.084 System.Runtime.InteropServices.JavaScript.wasm.br
11.749 nkast.Wasm.Canvas.wasm.br
11.591 Primitives3D.wasm.br
9.320 System.Text.Encodings.Web.wasm.br
9.275 Microsoft.Extensions.Logging.Abstractions.wasm.br
7.738 System.Linq.wasm.br
7.600 System.Collections.wasm.br
7.461 System.Collections.Concurrent.wasm.br
6.844 Microsoft.Extensions.Logging.wasm.br
6.252 Microsoft.Extensions.Options.wasm.br
6.043 nkast.Wasm.Dom.wasm.br
5.693 System.Console.wasm.br
5.457 System.Memory.wasm.br
5.106 Microsoft.Extensions.DependencyInjection.Abstractions.wasm.br
4.758 Xna.Framework.Media.wasm.br
4.458 Xna.Framework.Audio.wasm.br
4.309 nkast.Wasm.Audio.wasm.br
4.126 Microsoft.JSInterop.WebAssembly.wasm.br
4.019 Microsoft.Extensions.Primitives.wasm.br
3.077 Microsoft.Extensions.Configuration.Json.wasm.br
2.980 System.Net.Http.wasm.br
2.967 Microsoft.Extensions.Configuration.wasm.br
2.353 blazor.boot.json.br
1.992 System.Drawing.Primitives.wasm.br
1.861 Microsoft.Extensions.Configuration.Abstractions.wasm.br
1.807 System.Runtime.wasm.br
1.699 System.ObjectModel.wasm.br
1.593 System.Runtime.Serialization.Primitives.wasm.br
1.493 System.Net.Primitives.wasm.br
1.493 nkast.Wasm.XHR.wasm.br
1.457 System.ComponentModel.TypeConverter.wasm.br
1.353 System.ComponentModel.wasm.br
1.343 System.Drawing.wasm.br
54 File(s) 3.004.642 bytes

[dtaylorus]

My game is taking about 6 seconds on first load, while my competitor's games built with Javascript/HTML5 frameworks have sub-second load times that feel almost instant. So anything that can be done to remove unnecessary dependencies and improve load time would be most welcome, at least for my projects.

I haven't seen any benchmarks comparing the load time of a plain wasm build with a Blazor wasm build, so I don't know how much of an improvement we're talking about here, but any improvement would be appreciated.

From what I've read it seems like AOT + full trimming can significantly reduce the deployed project size and reduce load times.

I tried trimming the BlazorGL project and ran into dotnet/aspnetcore#49409 which seems to say that Blazor itself is not trimmable and it doesn't look like it's a priority for the Blazor team to fix. On the other hand, the Silk.NET team was able to make their project fully trimmable without Blazor (see https://perksey.com/blog/blazor-silkdotnet.html).

So it seems like removing the Blazor dependency could unblock some potential load time improvements, and if I understand correctly, the Blazor API's aren't an intentional part of the API surface of the game engine anyway (since they can never be cross-platform, e.g., for WindowsDX), so they could be removed without impacting the engine.

Anyway, I appreciate your thoughts on your long-term goals for the Blazor dependency, and if you'd like to remove it I may have some time to help.

[nkast]

I found some interesting stuff following those links.

There is this video ,
and some hints that you can go down to 1.5MB (br compression).

This sample is supposed to be ~1MB when published.
https://github.com/danroth27/SatelliteSimulator/tree/main
We can use it a a base to refine our template and remove some .razor pages and components.

some suggest to add those properties,
true
false

I already had the BlazorEnableTimeZoneSupport in the template.
I am not so sure about enabling InvariantGlobalization, it might not be good for a game,
but it's fine for an add or a sample. So, I am leaving it up to the user to enable it.

I've tested it on Primitives3D and _framework\ went down to 1.943.445 Bytes.
64.1% of what it was before.

Also, if you are hosting on a static server, make sure you set enableBrotliDecompression=true inside index.html

[dtaylorus]

Thanks for the tips! I did need the local time so I ended up using the following Javascript:

export function getLocalTimeZoneOffset()
{
    return new Date().getTimezoneOffset();
}

and I'm invoking it synchronously with IJSInProcessObjectReference.Invoke<int>().

I'll experiment with some of the other settings soon.

Btw, I've got a bunch of other changes for making a BlazorGL game work well as a full screen PWA which requires some style changes in index.html and getting the safe area which isn't currently being set in TitleSafeArea. It's a bit of a tricky hack so I'll share it when I clean it up a bit. The good news is with these changes the BlazorGL game is pretty much visually indistinguishable from the app.

(Also there's a missing </div> in the BlazorGL index.html template which I've been meaning to file as an issue. I'll get around to it eventually!)

[dtaylorus]

Is it fair to say that you intend to keep the Blazor dependency long term? I definitely want to remove it for my own purposes, and it would be great if that's the direction you're headed as well.

[dtaylorus]

Note that one of the issues requiring a workaround in the webassembly build has been resolved as noted in dotnet/runtime#99176