SDL2 without hardware acceleration

Hi there, I’m new to SDL development and have a question about the use of SDL2 without hardware acceleration.

I’m developing a simple control panel style graphical application for an industrial controller device, which shows diagrams of the installation, so the operator can see the state of the process and issue commands from the UI. The app is to run on Linux directly over the X11 server without a desktop environment.

I’m a bit confused about a certain aspect of SDL2 which is the Texture API. My hardware platform doesn’t support hardware acceleration, so I must use software rendering. My question regarding this is, should I still use the SDL_Texture and SDL_Renderer structures or should I use SDL_Surface?

Is it the same from a performance perspective?

I look forward to your replies.


You can use the SDL_Renderer API with a software renderer, and if you update your system with a 3D capable display, you’ll automatically get performance improvements. If you already have a software rendering system that renders into a buffer, then it may be simpler to use SDL_Surface. In this case, the performance should be similar with either solution.

Thanks for your reply.

I just ported my SDL app to use the SDL_Renderer API using software rendering and it runs as good (even a bit faster) as the version using SDL_Surface. I think it’s actually better becasue the API has native texture rotation support, which is way better than the SDL_gfx extension library I was using (it was a nightmare to reposition the surface after rotation with gfx).

So in conclusion, it seems better to go with the SDL_Renderer API even if you don’t have hardware acceleration…

I entirely agree, but it’s perhaps worth mentioning that I am using SDL_RenderCopyEx() to rotate a texture whilst at the same time using rotozoomSurfaceXY() (from SDL2_gfx) to rotate a matching surface, which I use for collision detection.

It’s not actually difficult to “reposition the surface” when you realise that its size (typically) changes on rotation. You simply need to make an adjustment corresponding to that difference in size.

Admittedly the fact that the rotation angle is clockwise for SDL_RenderCopyEx() but counter-clockwise for rotozoomSurfaceXY() is crazy, but it’s easy to compensate for!