Announcing the SDL 3.3 Preview!

SDL Announcements
1

This is a preview of the upcoming 3.4 release!

The API and ABI are still in progress, but we wanted to get a release out so everyone can try out the new features and provide feedback:

4 Likes
2

Added SDL_CreateGPURenderState(), SDL_SetGPURenderStateFragmentUniforms(), SDL_SetGPURenderState(), and SDL_DestroyGPURenderState() to use fragment shaders with a GPU 2D renderer

:eyes:

3

Hello SDL development team,

I am writing to express my concern regarding the recent addition of features like PNG image loading/saving in SDL 3.3.2.

I have long valued and relied on SDL for its core philosophy: to be a thin, cross-platform abstraction layer for system-specific multimedia functionality. Its strength was in providing unified access to windows, audio, input, and threading across different operating systems, and doing that one job exceptionally well. It was a reliable, minimal foundation upon which developers could build their own systems, choosing their own preferred libraries for tasks like image loading (e.g., stb_image, libpng).

The inclusion of a PNG codec feels like a significant shift away from this core principle. It blurs the line between a low-level platform abstraction layer and a higher-level utility framework. My primary concerns are:

  1. Philosophical Shift: This move risks diluting SDL’s unique value proposition. It is no longer a “layer” but is becoming a “kitchen sink” library.
  2. Maintenance Burden: Every new feature adds to the long-term maintenance burden. I would much prefer to see development resources focused on perfecting, optimizing, and stabilizing the core low-level functionality that we all depend on.
  3. Unnecessary Bloat: For many projects, this functionality is redundant, as they already use specialized libraries. It forces an optional dependency into the core, which goes against the principles of a minimal, composable toolset.

I strongly urge you to reconsider this direction. If such features are to be added, perhaps they should be strictly isolated in separate, optional libraries (like SDL_image has been historically) to keep the core library lean and focused.

Thank you for your time and for your continued work on this critical project.

Sincerely,
A concerned long-time SDL user.

4

It’s a legitimate concern, but we needed the PNG support ourselves because we were performing ridiculous acrobatics to avoid it.

3 Likes
5

Don’t worry, we share these concerns and our core philosophy hasn’t changed.

In this particular case, we needed PNG support for tray icons on Linux, and it’s extremely handy for test programs and working with the clipboard (which SDL already supports). Think of it just as the promotion of PNG to one of the core utility formats that SDL understands, like SDL_LoadBMP(). Our fundamental philosophy hasn’t changed.

3 Likes
6

Thank you for the clarification. I understand now - requiring png support for the tray API makes complete sense. this is indeed a necessary and justified decision rather than a philosophical shift.

Keep up the great work on SDL.

2 Likes