What is the point of an SDL2 Texture?

29
votes

I'm kind of stuck on the logic behind an SDL2 texture. To me, they are pointless since you cannot draw to them.

In my program, I have several surfaces (or what were surfaces before I switched to SDL2) that I just blitted together to form layers. Now, it seems, I have to create several renderers and textures to create the same effect since SDL_RenderCopy takes a texture pointer.

Not only that, but all renderers have to come from a window, which I understand, but still fouls me up a bit more.

This all seems extremely bulky and slow. Am I missing something? Is there a way to draw directly to a texture? What are the point of textures, and am I safe to have multiple (if not hundreds) of renderers in place of what were surfaces?

3
c++texturessdlrenderersdl-2
The way the architecture of SDL changed when they introduced 2.0 is forcing me into SFML. I just can't deal with re-structuring my entire program because of their API change; basically, there is no off-screen rendering like SFML supports. – Qix - MONICA WAS MISTREATED
SDL2 is in a pre-release state. It's not exactly fair to judge it just yet. In spite of being a WIP, the developer has been kind enough to let us mess with it as it progresses is all. – user1727324
@Di-0xide The old wiki is still available. libsdl.org/cgi/docwiki.cgi – Wes
Looking back on this 3 years later, I didn't understand what a graphics texture really was. For those of you still up-voting, remember textures are not necessarily pieces of images or graphics; they're really any data sent up to the card. – Qix - MONICA WAS MISTREATED
Another three year laters and a response I wrote for a Reddit ELI5 makes a bit of sense to link. It's a really bare-bones explanation of how graphics pipelines work and touches on some basic theory. Good diving off point if anyone finding this is completely new to the subject. – Qix - MONICA WAS MISTREATED

3 Answers

39
votes

SDL_Texture objects are stored as close as possible to video card memory and therefore can easily be accelerated by your GPU. Resizing, alpha blending, anti-aliasing and almost any compute-heavy operation can harshly be affected by this performance boost. If your program needs to run a per-pixel logic on your textures, you are encouraged to convert your textures into surfaces temporarily. Achieving a workaround with streaming textures is also possible.

Edit: Since this answer recieves quite the attention, I'd like to elaborate my suggestion.

If you prefer to use Texture -> Surface -> Texture workflow to apply your per-pixel operation, make sure you cache your final texture unless you need to recalculate it on every render cycle. Textures in this solution are created with SDL_TEXTUREACCESS_STATIC flag.

Streaming textures (creation flag is SDL_TEXTUREACCESS_STREAMING) are encouraged for use cases where source of the pixel data is network, a device, a frameserver or some other source that is beyond SDL applications' full reach and when it is apparent that caching frames from source is inefficient or would not work.

It is possible to render on top of textures if they are created with SDL_TEXTUREACCESS_TARGET flag. This limits the source of the draw operation to other textures although this might already be what you required in the first place. "Textures as render targets" is one of the newest and least widely supported feature of SDL2.

Nerd info for curious readers:

Due to the nature of SDL implementation, the first two methods depend on application level read and copy operations, though they are optimized for suggested scenarios and fast enough for realtime applications.

Copying data from application level is almost always slow when compared to post-processing on GPU. If your requirements are more strict than what SDL can provide and your logic does not depend on some outer pixel data source, it would be sensible to allocate raw OpenGL textures painted from you SDL surfaces and apply shaders (GPU logic) to them.

Shaders are written in GLSL, a language which compiles into GPU assembly. Hardware/GPU Acceleration actually refers to code parallelized on GPU cores and using shaders is the prefered way to achieve that for rendering purposes.

Attention! Using raw OpenGL textures and shaders in conjunction with SDL rendering functions and structures might cause some unexpected conflicts or loss of flexibility provided by the library.

TLDR; It is faster to render and operate on textures than surfaces although modifying them can sometimes be cumborsome.

8
votes

Through creating a SDL2 Texture as a STREAMING type, one can lock and unlock the entire texture or just an area of pixels to perform direct pixel operations. One must create prior a SDL2 Surface, and link with lock-unlock as follows:

SDL_Surface surface = SDL_CreateSurface(..);
SDL_LockTexture(texture, &rect, &surface->pixels, &surface->pitch);
// paint into surface pixels
SDL_UnlockTexture(texture);

The key is, if you draw to texture of larger size, and the drawing is incremental ( e.g. data graph in real time ) be sure to only lock and unlock the actual area to update. Otherwise the operations will be slow, with heavy memory copying.

I have experienced reasonable performance and the usage model is not too difficult to understand.

6
votes

In SDL2 it is possible to render off-screen / render directly to a texture. The function to use is:

int SDL_SetRenderTarget(SDL_Renderer *renderer, SDL_Texture *texture);

This only works if the renderer enables SDL_RENDERER_TARGETTEXTURE.