Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><code>SDL_Texture</code> 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.</p> <p><strong>Edit</strong>: Since this answer recieves quite the attention, I'd like to elaborate my suggestion.</p> <p>If you prefer to use <code>Texture -&gt; Surface -&gt; Texture</code> 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 <code>SDL_TEXTUREACCESS_STATIC</code> flag.</p> <p>Streaming textures (creation flag is <code>SDL_TEXTUREACCESS_STREAMING</code>) 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.</p> <p>It is possible to render on top of textures if they are created with <code>SDL_TEXTUREACCESS_TARGET</code> 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.</p> <p><strong>Nerd info for curious readers:</strong></p> <p>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. </p> <p>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 <strong>shaders</strong> (GPU logic) to them. </p> <p>Shaders are written in GLSL, a language which compiles into GPU assembly. <strong>Hardware/GPU Acceleration</strong> actually refers to code parallelized on GPU cores and using shaders is the prefered way to achieve that for rendering purposes. </p> <p><strong>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.</strong> </p> <p><strong><em>TLDR;</em></strong> It is faster to render and operate on textures than surfaces although modifying them can sometimes be cumborsome.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload