Would be interesting to see a comparison to the recent “faster than png by being simpler” formats like QOI, or depending on what library SDL uses for png, perhaps something like fpng.
Looks like SDL2 itself does not provide PNG image support, so they are probably using sdl2-image, which uses libpng. So, per the benchmarks on the fpng page, fpng has “2.5-3x faster decompression (on fpng compressed PNG’s)” than libpng, and the default QOI lib is in the same ballpark as fpng. There are faster QOI libs, but by a factor or two, but not 10x. Sooooooooo… QOI would probably get in a similar space to LZ4 but might not beat it.
That was exactly my thought. SDL_image isn’t exactly known for it’s performance. Also the perf of QOI can be good.
Neat if niche problem, and weird if pragmatic solution. Surprised that this wheel hasn’t been reinvented more often, but I can’t think of many other comparable image formats that might decode faster. webp? tiff?
It’s weird that SDL doesn’t provide a way to work with textures in S3TC format, which has been natively supported by GPUs since DirectX 6.0 and OpenGL 1.3. It probably doesn’t compress as well as PNG, but you’d save all the CPU time spent on decompression and conversion - just upload from disk straight into VRAM.
SDL is really much more about handling input and such than actually drawing. Almost every nontrivial game I’ve seen with SDL uses it to provide an OpenGL context, and then writes its own OpenGL code for actual graphics.
Also the wikipedia page notes “Hand-drawn cartoon-like images do not compress well [with S3TC]…”, similar to JPEG, so I wouldn’t expect it to work well in this case anyway. Don’t know how big a problem that is in practice though.
SDL is more focused on covering up the differences between platforms, than being a game engine specifically. Platform-neutral functionality is almost always pushed off to third-party add-on libraries.