Replace platform independent windowing/display code with a unified SDL3 version

[LouChiSoft]

Discussion instead of a formal proposal since there might be a reason for it being this way. I asked on the forums if there was a specific technical reason why Godot uses separate code for every platform it supports instead of a library like SDL3 to abstract as much of it away to unified code as possible but it seemed no one knows why it is that way

For context I was attempting to replace the default title bar on Windows with a custom one that uses tabs to move some of the main Editor functionality into separate tabs. Instead I was met with a mess of Win32 apis that are less than ideal to program. By contrast I was able to spin up an SDL based program with a borderless window and resizable edges in about 10 minutes.

I've seen that SDL is used elsewhere in the engine (I think for inputs) so I was wondering what the rationale behind not using it for the windowing system was. And if there isn't really a rationale, what's stopping it from being replaced with a more unified option.

Thanks

[theraot]

As far as I can gather, it is because Godot could implement the features it needs instead of waiting for SDL to add them. We wait for Godot instead.

Larvita3 engine (a precursor to Godot, although open sourced afterwards), uses SDL. But back then it didn't do everything that Godot needed. In fact, Juan got a disdain for relying on a third party. In this case the issue is Godot and SDL goals did not aligning, so when Godot needed a feature from SDL there was no guarantee that SDL would add it. See: https://x.com/reduzio/status/1770036784530903355

You might argue that SDL has most of what Godot needs now, yet it takes time and effort to migrate, and it is unclear what gain is to be made - granted I say this not having used SDL recently. Or if it will become a problem in the future.

By the way, not using SDL, for both good an ill, means that Godot can do and needs its own optimization, and can have and needs its own console porting independently.

You might be interested in:

• Switch to SDL as the main gamepad input driver #9000

[LouChiSoft]

Thanks for the reply. I did wonder if that was going to be the case. I completely understand the frustration of a 3rd party dependency not implementing a feature or requirement in a timely manner for your project.

I can't speak for back when Larvita3 used it, but I am yet to find an example of something I couldn't do with an SDL Window that I could do with the raw platform APIs. And given that you can also get the underlying HWND on Windows and presumably their Linux/Macos counterparts on other platforms I would assume that if that problem did come up it would be possible to get the raw handle, call the necessary APIs and then continue on with the SDL_Window pointer.

Thanks for the link to the SDL input post. I do think that actually if SDL was going to be implemented for the input then doing it for the window wouldn't be a bad idea anyway since those two particular subsystems interact so close to each other (windows generates intputs, etc.). But I would probably stop there unless there is a good reason to use another subsystem.

I'd be willing to attempt to integrate an SDL based version of the platform code. But I would probably need some assistance in figuring out what exactly I need to replicate to have a working version. But that would only be if there is a chance that it would be accepted into the engine. I'd like not to spend however many hours it would take to learn and integrate a new platform if it is always going to be shot down.

Thanks for your reply

[AThousandShips]

Additionally we'd still need our own system to be able to port to platforms SDL might not support, having our own backend makes this much easier for third party porting providers, where I doubt SDL provide any support for the same reason we don't provide console ports directly

[LouChiSoft]

Oh, I don't think that it should be re-written in such a way that it prevents other platform backends from being added. I think that if anything an SDL backend could be added in the exact same way that the current platforms are added. And then, assuming everything works as intended, removing the bespoke backends for the public platforms. And since I assume console platforms are added in the same way as described here, then unless I am missing something, I don't see how adding SDL would prevent people from still being able to add platforms not supported by Godot out of the box. And in terms of the current gen consoles SDL does support the Switch, PS4 & PS5. So as far as I can tell the only missing platforms would be the XBox and the Switch 2 when that comes out.

I just think that if within reason you could convert all the public platforms into a single "SDL" platform and then have custom/NDA's platforms added as described in the docs then it would be at least worth the investigation. Especially, if like theraot's post links to, the engine is using SDL elsewhere for other parts of the engine.