Investigate adding SDL backend for kapp (kapp-sdl)

[lunabunn]

Tracking issue for investigating (not necessarily actually implementing) an SDL backend for kapp. This should be a separate crate (kapp-sdl) within this repository that is exposed through kapp via a feature-gated dependency.

Benefits:

• Have a portable, production-ready, and battle-tested alternative implementation for production builds
• Verify that kapp's API is sensible and matches certain "expectations" set by SDL
• Easier to implement features that aren't yet available in core kapp (more freedom to play around with the API if stuff is actually implemented, we can aim for eventual feature parity)
• Act as a nice, Rusty wrapper around SDL

Points for consideration:

• This would obviously be more work to maintain
• #44 mentions smooth window resizing as one of kapp's goals, but SDL can't do this
• Which set of SDL bindings should we use? fermium? sdl2? Own set of bindings?

Thoughts?

[kettle11]

Definitely worth seriously considering! I'll go through your points and add my thoughts. On a high-level I'm optimistic that it might not be as much work as it initially seems. The time consuming part would probably be managing weird event-flow quirks.

Have a portable, production-ready, and battle-tested alternative implementation for production builds

The portability is seriously useful. The battle-tested-ness would take a little time to be confident in because we'd inevitably introduce quirks on the kapp side.

Verify that kapp's API is sensible and matches certain "expectations" set by SDL

This is always useful. Each platform I've ported kapp to has revealed new ways to think about things. What I'd be careful of here is that we don't adopt weird quirks SDL has accumulated. It does a few things weird or wrong.

Easier to implement features that aren't yet available in core kapp (more freedom to play around with the API if stuff is actually implemented, we can aim for eventual feature parity)

Yup!

Act as a nice, Rusty wrapper around SDL

Yeah, that could be really handy. kapp would become a pragmatic choice to build great things now, but with an eye towards a Rust-only future.

This would obviously be more work to maintain

Of course, but it may not be too bad!

#44 mentions smooth window resizing as one of kapp's goals, but SDL can't do this

If I'm remembering correctly this is nearly possible with SDL. It's just hard, and very unsafe. I may be wrong here, but I definitely tried in the past and I have the code somewhere I could dig up. It's OK if the SDL backend is a little less good and we clearly document it.

Which set of SDL bindings should we use? fermium? sdl2? Own set of bindings?

I'd prefer to use fermium if possible as @lokathor makes great stuff and is fun to work with. That is unless there's a major gain we get from writing our own bindings (in terms of compile-times or otherwise), but it doesn't seem like there would be.

---

Another thought worth getting down here:

kapp (not the OpenGL part) has a pretty clean separation between the front-end and back-end parts. It may be possible to tweak kapp slightly to allow for backends to be in a separate crate entirely.

This could allow experimental backends (like an SDL backend) to be published separately, or for people to make their own backends that they'd like to make available.

[kettle11]

This is a good idea to investigate. I started coding it on this branch: https://github.com/kettle11/kapp/tree/SDL

So far all that happens is a window can be opened, and the event loop runs but no events are sent. Filling out the rest shouldn't be too bad!

[Lokathor]

I would like fermium to continue to be the best raw SDL2 bindings available.

However, while I fully trust the C bindings written in the rust code, the build.rs isn't quite as perfectly robust as I'd like. Currently it cannot really do cross-compilation, for example, which also makes it not so likely to work with android or ios. This is one of those "I use Windows mainly and it works perfectly fine for me on Windows, and I lack some of the unix expertise to make it work better on mac/linux"

It totally builds on Mac / Linux, but it will build the C lib from scratch each time (1-2 minutes), which leads to a poor first build. I know that @thomcc had an idea that we could maybe setup a cache directory that a user could set to preserve the C artifacts between cargo clean usages. Unfortunately the system files for SDL2 are often out of date on Linux, so "just use the version installed to the system" is not entirely helpful.