Hello,
Do I understand correctly that in 1.3 textures are tied with the
current renderer and hardware, whereas surfaces are just software
abstractions that work with heap memory?
I’m asking this just to understand where everything resides. What is
stored in the video memory and benefits from hardware acceleration
(DirectX, in my case) and what is handled using typical C memory
management and needs to be copied to the video card after each update?
Suppose I had a number of small bitmaps that needed to be combined
into a single frame. Is it more efficient to use surfaces with
SDL_BlitSurface function, followed by SDL_CreateTextureFromSurface,
and finally one SDL_RenderCopy call, or should I just allocate several
textures, draw on them using my own routines, and then copy them one
by one with SDL_RenderCopy?
I just don’t have a clear idea of what is being transferred where and
how quickly with these different functions. For example, what are the
implications of creating textures with SDL_TEXTUREACCESS_STATIC versus
SDL_TEXTUREACCESS_STREAMING? I looked around, but couldn’t find any
pros and cons for each.
Maxim Khitrov wrote:
Hello,
Do I understand correctly that in 1.3 textures are tied with the
current renderer and hardware, whereas surfaces are just software
abstractions that work with heap memory?
Correct.
I’m asking this just to understand where everything resides. What is
stored in the video memory and benefits from hardware acceleration
(DirectX, in my case) and what is handled using typical C memory
management and needs to be copied to the video card after each update?
In SDL 1.3 surfaces are always stored in application (client) memory. Textures are
managed by renderer driver which means that they are probably stored
in graphics hardware (server) memory (if total size of textures exceeds
sizeo of hw memory driver will move them to app memory).
Suppose I had a number of small bitmaps that needed to be combined
into a single frame. Is it more efficient to use surfaces with
SDL_BlitSurface function, followed by SDL_CreateTextureFromSurface,
and finally one SDL_RenderCopy call, or should I just allocate several
textures, draw on them using my own routines, and then copy them one
by one with SDL_RenderCopy?
Process of creating a texture and uploading its data is considered expensive.
Therefore you should create textures once and then put them on screen with
SDL_RenderCopy multiple times. In SDL 1.3 surfaces are only intermediate
objects to be passed to SDL_CreateTextureFromSurface().
Putting multiple textures on the screen is way more efficient than creating
surface first and then converting it to texture which involves data manipulation
on claint side + uplading data to hw each frame.
[qute]
I just don’t have a clear idea of what is being transferred where and
how quickly with these different functions. For example, what are the
implications of creating textures with SDL_TEXTUREACCESS_STATIC versus
SDL_TEXTUREACCESS_STREAMING? I looked around, but couldn’t find any
pros and cons for each.
Once texture is created and data uplaoded (which hapens at init time)
each SDL_RenderCopy call is very cheap (and I mean very cheap).
STATIC vs STREAMING is a hint to the driver about how texture will be used
by application. STATIC means that texture will never (or very seldom)
be modified, STREAMING otoh means that texture data will be modified
more often. This helps the driver to decide how to store and manage textures
under the hood.
Thanks for those explanations!
- MaxOn Sat, Oct 2, 2010 at 2:25 PM, hardcoder wrote:
Maxim Khitrov wrote:
Hello,
Do I understand correctly that in 1.3 textures are tied with the
current renderer and hardware, whereas surfaces are just software
abstractions that work with heap memory?
Correct.
Quote:
I’m asking this just to understand where everything resides. What is
stored in the video memory and benefits from hardware acceleration
(DirectX, in my case) and what is handled using typical C memory
management and needs to be copied to the video card after each update?
In SDL 1.3 surfaces are always stored in application (client) memory. Textures are
managed by renderer driver which means that they are probably stored
in graphics hardware (server) memory (if total size of textures exceeds
sizeo of hw memory driver will move them to app memory).
Quote:
Suppose I had a number of small bitmaps that needed to be combined
into a single frame. Is it more efficient to use surfaces with
SDL_BlitSurface function, followed by SDL_CreateTextureFromSurface,
and finally one SDL_RenderCopy call, or should I just allocate several
textures, draw on them using my own routines, and then copy them one
by one with SDL_RenderCopy?
Process of creating a texture and uploading its data is considered expensive.
Therefore you should create textures once and then put them on screen with
SDL_RenderCopy multiple times. In SDL 1.3 surfaces are only intermediate
objects to be passed to SDL_CreateTextureFromSurface().
Putting multiple textures on the screen is way more efficient than creating
surface first and then converting it to texture which involves data manipulation
on claint side + uplading data to hw each frame.
[qute]
I just don’t have a clear idea of what is being transferred where and
how quickly with these different functions. For example, what are the
implications of creating textures with SDL_TEXTUREACCESS_STATIC versus
SDL_TEXTUREACCESS_STREAMING? I looked around, but couldn’t find any
pros and cons for each.
Once texture is created and data uplaoded (which hapens at init time)
each SDL_RenderCopy call is very cheap (and I mean very cheap).
STATIC vs STREAMING is a hint to the driver about how texture will be used
by application. STATIC means that texture will never (or very seldom)
be modified, STREAMING otoh means that texture data will be modified
more often. This helps the driver to decide how to store and manage textures
under the hood.