SDL1 and SDL2

27 views
Skip to first unread message

Alon Zakai

unread,
Jun 3, 2023, 12:52:20 AM6/3/23
to emscripte...@googlegroups.com
Hi everyone,

I wonder if we still need our SDL1 (SDL 1.2, specifically) implementation at this time, given that we have excellent and stable SDL2 support?

Context: SDL1 has been deprecated for many years now [1]. SDL2 is a decade old at this point [2], and other projects have removed SDL1 support (e.g. [3]). In fact, SDL is working on SDL3 now [4].

Historically, I think SDL1 was Emscripten's first supported graphics API, and that code is quite old and quirky, as I'm noticing while I'm working on WasmFS. The later SDL2 port was done in a much better way (and WasmFS, in particular, "just works" with it, unlike SDL1). So removing the weird SDL1 code could help speed up our development.

Is anyone using SDL1 and unable to upgrade to SDL2 (or to glfw etc.) for some reason?

- Alon

Floh

unread,
Jun 7, 2023, 8:35:56 AM6/7/23
to emscripten-discuss
I wonder whether most of those old "portability wrappers" shouldn't be deprecated tbh (SDL2 might be special because it has "official" upstream support now?).

Those wrappers were very helpful in the beginning to get things started, but for instance (as far as I noticed) Dear ImGui was running into quite a few confusing differences recently between Emscripten's GLFW wrapper and "native" GLFW (mainly subtle things like mouse wheel input events behaving differently).

When people see Emscripten's GLFW support they probably expect that it behaves identical with the "official" GLFW, but this would mean putting a lot of effort into the "GLFW emulation" which should better go into the "core product" (for instance more C API wrappers for web APIs).

Anyway, just my 2ct :)



Sam Clegg

unread,
Jun 7, 2023, 12:16:10 PM6/7/23
to emscripte...@googlegroups.com
On Wed, Jun 7, 2023 at 5:36 AM Floh <flo...@gmail.com> wrote:
I wonder whether most of those old "portability wrappers" shouldn't be deprecated tbh (SDL2 might be special because it has "official" upstream support now?).

Those wrappers were very helpful in the beginning to get things started, but for instance (as far as I noticed) Dear ImGui was running into quite a few confusing differences recently between Emscripten's GLFW wrapper and "native" GLFW (mainly subtle things like mouse wheel input events behaving differently).

When people see Emscripten's GLFW support they probably expect that it behaves identical with the "official" GLFW, but this would mean putting a lot of effort into the "GLFW emulation" which should better go into the "core product" (for instance more C API wrappers for web APIs).


Are you suggesting that we could somehow use upstream GLFW?  That seems unlikely since GLFW interacts so closely with input events and the display.. it seems like we would need a specific emscripten of that library.  Or are you suggesting we invest in a  port to emscripten in the upststram GLFW repo?

I don't how that would prevent  bugs like `mouse wheel input events behaving differently` since those could still conceivably occur, even in an upstream port simply due to the what the mouse wheel events are reported by the browser, no?

Anyway, just my 2ct :)



On Saturday, 3 June 2023 at 06:52:20 UTC+2 alon...@gmail.com wrote:
Hi everyone,

I wonder if we still need our SDL1 (SDL 1.2, specifically) implementation at this time, given that we have excellent and stable SDL2 support?

Context: SDL1 has been deprecated for many years now [1]. SDL2 is a decade old at this point [2], and other projects have removed SDL1 support (e.g. [3]). In fact, SDL is working on SDL3 now [4].

Historically, I think SDL1 was Emscripten's first supported graphics API, and that code is quite old and quirky, as I'm noticing while I'm working on WasmFS. The later SDL2 port was done in a much better way (and WasmFS, in particular, "just works" with it, unlike SDL1). So removing the weird SDL1 code could help speed up our development. 
--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/903c41e4-19e3-4fde-9816-312f1e7da3d4n%40googlegroups.com.

Alon Zakai

unread,
Jun 7, 2023, 1:29:50 PM6/7/23
to emscripte...@googlegroups.com
Yeah, this is tricky. I agree with Floh that our early ports of glfw etc. are of limited use. Ideally they'd all be done like SDL2, that is, be in upstream + use emscripten HTML5 C APIs as much as possible, to get consistent input event handling etc., which is a common issue as you said, Sam.

Still, I'd like to remove SDL1 specifically because we do have an obvious replacement, SDL2, which is also our best such implementation.

- Alon


To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28cyxzdtfPTYJD1rCqN3OSy-qW_Mqpf2YLc6vZ2NE6MZA%40mail.gmail.com.

Sam Clegg

unread,
Jun 7, 2023, 3:41:29 PM6/7/23
to emscripte...@googlegroups.com
On Wed, Jun 7, 2023 at 10:29 AM Alon Zakai <alon...@gmail.com> wrote:
Yeah, this is tricky. I agree with Floh that our early ports of glfw etc. are of limited use. Ideally they'd all be done like SDL2, that is, be in upstream + use emscripten HTML5 C APIs as much as possible, to get consistent input event handling etc., which is a common issue as you said, Sam.

Still, I'd like to remove SDL1 specifically because we do have an obvious replacement, SDL2, which is also our best such implementation.

Although I'm normally in favor of removing stuff.. I'm not sure we have a good reason to in this case.   It doesn't cost us much to maintain does it?
 

Alon Zakai

unread,
Jun 7, 2023, 4:02:23 PM6/7/23
to emscripte...@googlegroups.com
As I said at the start, it does become somewhat annoying to fully maintain with WasmFS. We've found a way to work around some of that in


but more remains (right now I'm looking at some closure issues related to it). It is just awkward to access the filesystem from JS in a JS-ey way when it is written in wasm - we're going to try to make the WasmFS JS API as good as possible, but it can't be perfect (e.g. we probably won't create all the objects the current JS FS provides JS, like the return object of FS.analyzePath etc.).

- Alon


To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-rCxkKV_6%3D2eT7%2B0CtqyD26z_3nxR7CMJ_hXgUEw8zzw%40mail.gmail.com.

Sam Clegg

unread,
Jun 7, 2023, 4:40:24 PM6/7/23
to emscripte...@googlegroups.com
On Wed, Jun 7, 2023 at 1:02 PM Alon Zakai <alon...@gmail.com> wrote:
As I said at the start, it does become somewhat annoying to fully maintain with WasmFS. We've found a way to work around some of that in


but more remains (right now I'm looking at some closure issues related to it). It is just awkward to access the filesystem from JS in a JS-ey way when it is written in wasm - we're going to try to make the WasmFS JS API as good as possible, but it can't be perfect (e.g. we probably won't create all the objects the current JS FS provides JS, like the return object of FS.analyzePath etc.).

If we decide we can't (or don't want to) fully emulate the old JS FS API, and SDL1 depends on that old API then I agree that might be an argument for perhaps removing SDL1.  But removing it simply because it uses the existing API seems wrong.  As it stands it is providing us with a good test case for the type of FS API usage that might be out in the wild and its actually useful to wasmfs development to have that.

Floh

unread,
Jun 8, 2023, 3:41:18 AM6/8/23
to emscripten-discuss
Are you suggesting that we could somehow use upstream GLFW?  That seems unlikely since GLFW interacts so closely with input events and the display.. it seems like we would need a specific emscripten of that library.  Or are you suggesting we invest in a  port to emscripten in the upststram GLFW repo?

No, just deprecate the Emscripten GLFW wrapper and instead pitch the HTML5 functions for WebGL context setup and input events (https://emscripten.org/docs/api_reference/html5.h.html) :)

Most existing native GLFW code is written in an "own the game loop" model and would need Emscripten specific tweaks anyway, and at the same time, the GLFW API isn't so big that it would be a lot of work to replace.

Александр Гурьянов

unread,
Jun 9, 2023, 6:02:37 AM6/9/23
to emscripte...@googlegroups.com
I use SDL 1 in many project, because it's more lightweight, anyway I think for me it's not a problem, because I can switch to older versions of emsc.

чт, 8 июн. 2023 г. в 09:41, Floh <flo...@gmail.com>:
Are you suggesting that we could somehow use upstream GLFW?  That seems unlikely since GLFW interacts so closely with input events and the display.. it seems like we would need a specific emscripten of that library.  Or are you suggesting we invest in a  port to emscripten in the upststram GLFW repo?

No, just deprecate the Emscripten GLFW wrapper and instead pitch the HTML5 functions for WebGL context setup and input events (https://emscripten.org/docs/api_reference/html5.h.html) :)

Most existing native GLFW code is written in an "own the game loop" model and would need Emscripten specific tweaks anyway, and at the same time, the GLFW API isn't so big that it would be a lot of work to replace.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/b175b4bc-4662-4e6f-a35d-69ebfec1303cn%40googlegroups.com.

Alon Zakai

unread,
Jun 9, 2023, 1:16:57 PM6/9/23
to emscripte...@googlegroups.com
Thanks, good to know that this is being used. Sam already mostly convinced me to keep SDL1 around already, so with this information I think we can decide to keep it.

- Alon



To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFOisuwQsPxhH7pOiaoqmFVsh9x04gGgEhAp1qKCPWquQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages