Tracking issue for WebGL / WebAssembly

[HurricanKai]

This issue partially relies on the idea of (GL) API interfaces.

• [In Progress] Emscripten (-> theoretically possible for 2.0 but quite unlikely [sponsor us 🙂])
  • [In Progress] Initial Blazor WebAssembly version allow as-is running of existing OpenGL(ES) programs using the Emscripten OpenGL support
  • [In Progress] Use Emscripten GLFW & SDL to support Windowing
• [Not Started] JavaScript (this is the true WebGL, the above "simply" cross-compiles "normal" GL code to WebGL (-> guaranteed 3.0)
  • [Not Started] Look at how to implement function loading backed by I(InProcess)JSRuntime (-> Is it worth it supporting the async JSRuntime here [-> Blazor Server], I don't think so right now)

[sps014]

• [Not Started] Look at how to implement function loading backed by I(InProcess)JSRuntime (-> Is it worth it supporting the async JSRuntime here [-> Blazor Server], I don't think so right now)

Currently IJSInProcessRuntime is only implemented for Blazor WASM because Blazor Server runs in a separate process from the Browser. dotnet/aspnetcore#37926

I think blazor Server not worth supporting as of now.

[Beyley]

This issue partially relies on the idea of (GL) API interfaces.

* [ ]  [In Progress] Emscripten (-> theoretically possible for 2.0 but quite unlikely [sponsor us slightly_smiling_face])
  
  * [ ]  [In Progress] Initial Blazor WebAssembly version allow as-is running of existing OpenGL(ES) programs using the Emscripten OpenGL support
  * [ ]  [In Progress] Use Emscripten GLFW & SDL to support Windowing

* [ ]  [Not Started] JavaScript (this is the true WebGL, the above "simply" cross-compiles "normal" GL code to WebGL (-> guaranteed 3.0)
  
  * [ ]  [Not Started] Look at how to implement function loading backed by I(InProcess)JSRuntime (-> Is it worth it supporting the async JSRuntime here [-> Blazor Server], I don't think so right now)

Going to note what ive managed to complete in the wasm-take-3 branch

Compiling with Emscripten works, OpenGL functions run, SDL code runs

current blocker seems to be a hard to isolate runtime bug making some native functions just stop working sometimes

[Perksey]

I think this is absolutely a target for 3.0. I have managed to hack together a fully working sample against 2.X, and most of the issues encountered here were as a result of the really shoddy retro-fitted mechanisms in SilkTouch (raise your pitch forks at yours truly, it's my fault haha) for AOT support which 3.0 is already designed against.

This will be through Emscripten as this has been the most promising avenue of enquiry thus far.

[RedMike]

I think this is absolutely a target for 3.0. I have managed to hack together a fully working sample against 2.X, and most of the issues encountered here were as a result of the really shoddy retro-fitted mechanisms in SilkTouch (raise your pitch forks at yours truly, it's my fault haha) for AOT support which 3.0 is already designed against.

This will be through Emscripten as this has been the most promising avenue of enquiry thus far.

Came across the post referenced here a while back. I haven't actually used Silk.NET but I was trying to solve the same problems porting to WASM for other libraries (SDL, MonoGame, etc).

I've gotten a bit further than this and set up a working sample that avoids some of the mentioned problems (having to use _WasmPInvokeModules/add a target), improves some of the usability of what's there (setting the main loop without C interop, needing __Internal_emscripten at all), and avoids the need to unfreeze the cache (albeit having to therefore include a built SDL library yourself for now): https://github.com/RedMike/SdlWasmSample

I've also set up a branch on it for MonoGame, where that library used dynamic linking to load SDL (which doesn't work on Emscripten), therefore showing a way around those issues via function pointers/delegates without requiring super complex changes. It's not in the repo, but I've also had lots of luck using [LibraryImport] instead of [DllImport] to avoid the tons of marshalling complexity around strings and more, and it's all fully AOT-compatible too.

The README file in the repo explains the full set of changes and references back to that blog post where relevant to show alternatives. Hope this helps.