[platform] Discussion about raylib & emscripten

[ypujante]

I am creating this ticket as a follow up to a bunch of conversations that happened throughout various tickets and pull requests created in the past right before the release of raylib 5.0.

This discussion is about the raylib web platform and the usage of emscripten.

The status (as of raylib 5.0) for the web platform is to use emscripten/glfw.

This implementation currently works fine since it is the one used for all the raylib examples. That being said it has a lot of limitations as indicated by the many unimplemented APIs.

The purpose of this ticket is to see whether there is a better alternative.

Disclaimer: I will not be offended if this ticket gets closed or leads nowhere. I am just trying to help, but I also understand that I do not have all the pieces/history of the project and it's fine to not want to move forward.

[ypujante]

To start the discussion, I want to share some data points that I gathered while doing work on emscripten:

• glfw is implemented directly in emscripten as a javascript library
• the platform web raylib API uses the C api which is wrapping this library (ex: glfwInit)
• it also uses emscripten C calls (ex: emscripten_set_window_title)
• and a few javascript calls (via EM_ASM and EM_JS)

glfw is not a very well supported API for emscripten:

Emscripten implements the Simple DirectMedia Layer API (SDL) for the browser environment, which provides low level access to audio, keyboard, mouse, joystick, and graphics hardware. Applications that use SDL typically require no input/output changes to run in the browser.
In addition, we have more limited support for glut, glfw, glew and xlib.

[ypujante]

SDL2 is actually an emscripten "port": the actual source code lives in the SDL library itself and emscripten is simply pulling it when you use the -sUSE_SDL=2 compilation/link flag.

This library is actually written in C and compiled to wasm when using the port.

Note that this library is already Hi DPI aware (via flag SDL_WINDOW_ALLOW_HIGHDPI)

Note that @ubkp already did an amazing job demonstrating that emscripten SDL can be used as a new or alternate raylib web platform (see PR). The PR also demonstrates that there are far more raylib APIs implemented due to the fact that emscripten/SDLs has more equivalent.

[ypujante]

Based on these initial observations I think:

• if raylib wants its own emscripten implementation (not using an extra layer) then the SDL library is the one to get inspiration from since it is written in C and it is more complete
• it would be very interesting if raylib became an emscripten port! users could simply use -sUSE_RAYLIB and voila, raylib is available

I also think that the PLATFORM_WEB_SDL direction from the PR should be investigated to see if it would be a better implementation than glfw.

[Peter0x44]

Thanks for the detailed investigation.
Just one thing which I noticed, for some reason you link:
https://github.com/raysan5/raylib/issues/docs/README-emscripten.md
which is 404
I suspect your comment is actually meant to link:
https://github.com/libsdl-org/SDL/blob/main/docs/README-emscripten.md

[ypujante]

@Peter0x44 Thank you for pointing out the copy/paste issue. I fixed it in the comment.

[raysan5]

@ypujante Thanks for the investigation and the recap. Here some info for completion:

• GLFW was the first backend used by raylib (Windows, Linux, macOS) and so the use for PLATFORM_WEB, because most of the platform code was shared with the other platforms.
• As commented, the library_glfw.js has some limitations and do not match the desktop equivalent, the mapping could not be equivalent due to the async nature of some processes on web.
• Along the years, new platforms have been added to raylib (Android, RPI desktop, RPI native/DRM). In all those cases, I tried to use the native libraries provided by the platform, always minimizing dependencies (and avoiding middle-libraries like SDL).
• About SDL, it's a BIG dependency that I tried to avoid in raylib for 10 years. One of the great benefits of raylib is that it is self-contained and relatively small in source code files. Adding SDL to raylib changes that.
• A couple of years ago I had the opportunity to teach gamedev at University using SDL, so, I really familiarized with the library and it help me to understand it better, I wrote an article comparing both libraries.
• With the new platform-split, it was a great opportunity to SDL as a proof-of-concept to add new possible backends to raylib but I personally prefer to use native platform libraries when possible than relying on a 3rd party library (despite I'm aware that it's rock-solid and super-well tested).
• Also, thanks to the new platform-split, now web platform is decoupled from desktop so, GLFW dependency could maybe be avoid in favor or a native implementation, more aligned with platform web.
• About the proposed PR for a web SDL platform alternative, I think it's already possible without the need of adding an extra platform, just doing some minor tweak to current SDL platform backend. More platforms imply more code to maintain.

In any case, as usual, maintenance is a big concern for me so, new platform additions or big code changes would require some maintainer.

[ypujante]

@raysan5 Thank you for providing history and context. It is always a pleasure to learn why things are the way they are and perspective moving forward. This helps a lot.

About SDL, it's a BIG dependency that I tried to avoid in raylib for 10 years. One of the great benefits of raylib is that it is self-contained and relatively small in source code files. Adding SDL to raylib changes that.

When I started my project (desktop ImGui based) I tried to use SDL and I agree that it was very big so I could not embed it and went with GLFW as well. That being said, as I was pointing out, when using the emscripten compiler, you don't need to embed SDL in raylib, nor need to worry about having it installed locally, nor how to compile it. It's all taken care of (which is pretty neat). But I totally see your point.

Also, thanks to the new platform-split, now web platform is decoupled from desktop so, GLFW dependency could maybe be avoid in favor or a native implementation, more aligned with platform web.

I think that it is definitely an interesting idea. As I suggested in one of the other issue/pr threads, when I have a few spare cycles, I can take a look at this and see how big of an effort that would be.

In any case, as usual, maintenance is a big concern for me so, new platform additions or big code changes would require some maintainer.

I feel like with a little more work on the platform split, it should be fairly easy to be able to add a new platform without requiring any changes to raylib at all, which would allow for external platforms that are neither created nor maintained by you. I do not know if this is something of interest to you, but this is something I could provide help as well with.

[raysan5]

I think that it is definitely an interesting idea. As I suggested in one of the other issue/pr threads, when I have a few spare cycles, I can take a look at this and see how big of an effort that would be.

Thanks, please, let me know. I think it shouldn't be that complex but it could require some redesign on how inputs are polled to deal with the async nature of browser... probably the previous callback-based mechanism won't work any more.

I feel like with a little more work on the platform split, it should be fairly easy to be able to add a new platform without requiring any changes to raylib at all, which would allow for external platforms that are neither created nor maintained by you. I do not know if this is something of interest to you, but this is something I could provide help as well with.

That's ok for me, actually, I'm already aware of some custom platform implementations using the new architecture: PS4/PSVita homebrew, not officially released yet.