>>25
SDL
— Prior to version 2, SDL's inefficient surface model prevented any kind of useful 3D-hardware-based acceleration. It still doesn't allow rendering using multiple textures or the same texture multiple times in one draw call. This overhead is not negligible.
— SDL GL has no notion of frame-skipping, even though interfaces such as WGL_EXT_swap_control and GLX_SGI_swap_control support it.
— You cannot mix Direct3D or OpenGL and SDL rendering. This makes the SDL rendering interface's interest very dubious.
— SDL likes to pretend the refresh rate of the display in hertz is always an integer. While very few programs would be bothered by this (video players maybe?), it's just plain wrong.
— SDL promotes the use of timers which lack precision and are very cumbersome since, as the documentation explains, their use contaminates your program with pointless multithreading nonsense. It's best not to use them.
— The SDL doesn't provide functions for loading compressed data. This is not a sensible decision for a primarily game-oriented library. It's not consistent in this behaviour as it does provide functions for loading RIFF Wave and DIB files.