While we can always spend time investigating these kinds of issues, Blender’s audio support without SDL can still output to various back-ends via OpenAL as well as native support for PulseAudio on Linux, CoreAudio on macOS and WASAPI on MS-Windows.
Given this, the motivation to keep support for another audio back-end isn’t high.
To be removed:
SDL audio output won’t be included in release builds
(release builds will use WITH_SDL=OFF).
Blender’dynamic SDL linking will be removed.
(the WITH_SDL_DYNLOAD option, called sdlew internally).
SDL will be removed from pre-built libraries under ./lib/.
Edit: stand-alone cycles uses SDL, so the library can be kept in lib/ for now.
To be kept:
The WITH_SDL build option will remain, when enabled, audio output with SDL will be possible as before.
The WITH_GHOST_SDL build option, allowing Blender to run with SDL for windowing (used by Haiku).
Unless there are strong reasons to keep SDL support for 4.3, we intend to disable support for the up-coming release.
Something we’ve discusses in the Cycles chat root: cycles standalone depends on it. At a very least we’d need to coordinate that with the Cycles team.
Keeping in mind that Cycles is a BF project, and SDL doesn’t really need to be updated that often, and updates are typically easy, are there disadvantages of keeping its precompiled libraries?
Maybe @LazyDodo has some strong opinion here as well?
Nah SDL is a pretty small, quick to build and trouble free dep, if the cycles team wants to keep it it’s perfectly fine with me. Think brecht mentioned he may want a flag change, which is also fine with me.
Judging from the ticket linked which now has been root caused (and a pretty interesting one at that) I’m not seeing any clear reasons to disable SDL anymore (but will go along with whatever gets decided)
@sergey OK to keep in ./lib/ for cycles (edited post).
Even though the issue has been fixed in SDL2 I’d still rater disable SDL in release builds since we don’t gain much from it’s inclusion.
It’s one extra library to track, update etc (even integrating the fix from the new SDL2 takes us time).
SDL3 has recently been released with an updated API which seems different enough that sdlew and Blender’s SDL integration may need updating. Admittedly I’m not sure how much work this would be, just noting that this is something we would have to spend time on.
even if BGE was removed, the "interactivity mode" of Blender, in particular for “Blender Apps” and therefore input controller options like SDL ( that is not only for audio ) should be take in consideration before remove something that is already included from years.
I would prefer to not remove options for Linux users if it does not create critical problems because there is also to consider the ( upcoming ? ) “Blender Apps” project:
Blender Apps that could use SDL for interactive controller inputs.
EDIT: to avoid misunderstandings i removed examples that i referenced only for realtime interactivity but that are not using SDL
UPBGE for input controllers use SDL while for Audaspace audio can use OpenAL or SDL.
I gently ask not only to keep the SDL library ( as already stated ) but also to evaluate the support for SDL3 ( maybe with low priority ) for present and future possibility of Blender interactive projects ( Blender Apps ? ) that can use SDL in particular for the Input controls.
Thank you.
For the input devices we might indeed consider SDL3. But it is not as simple as just updating the library: the entire dynamic loader needs to be changed. But it is also not really clear whether it will be the library of choice to support all input devices we want to support. More dedicated investigation would need to happen.
For the audio I’d rather to focus on a single backend which works, than to have multiple backends with their own quirks. It just makes it easier for everyone.
The UPBGE can still compile with SDL, same as Blender for Haiku.
And for the add-ons this change doesn’t really have any affect: SDL was never exposed as Python API from Blender side.
The Blender Apps project was never considered to be a development framework, but more a customized Blender interface and existing Blender features. Disabling SDL does not affect it from this perspective: for audio output it is better to use PulseAudio (and upcoming Pipewire) to ensure proper A/V sync, i.e.
Also, keep in mind, if the library did not become a maintenance burden it would not have been considered for removal.
Thank you for the answer and the considerastion of SDL3
Talking about Blender Apps, it is not easy to know what direction will take in future ( when it will be available ).
For example also Grease Pencil was not considered to become what it is now but it was just an annotation tool initially
But i understand that Blender Apps project is not designed to be a Game Engine framework ( like the BGE ).
Still a solution for input devices like SDL3 ( or other libraries ) could be considered.
Just to chime in - OmniStep does not use SDL - (or any non-standard python library for that matter). It directly interfaces with the XInput interface of windows.
And as far as controller support goes - in SDL it is not that great to begin with… (based on my initial tests)
EDIT: To be clear it wrote " There are different projects that are based on Blender for realtime interactivity ( examples for interactivity , not always direct SDL usage ) "
I never wrote that your addon uses SDL.
I just wanted to underline the importance of realtime interactivity for Blender with very interesting examples, and in my opinion your addon seems very promising.
And, always in my opinion, Blender interactivity projects ( with a FOSS license for community support and collaboration ) could benefit a cross platform input solution like SDL.
But to avoid misunderstandings i removed the examples of realtime interactivity projects that are not using SDL.
As Linux user i know SDL for cross platform input solution.
If there are other better ( FOSS ) cross platform solutions, there is no need to focus only on SDL ( always in my personal opinion ).
