SDL_UnlockTexture really slow, what can I do?

SDL Development
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I noticed my texture creation lags the game notably, and I did a bit of
time measurement. It appears SDL_UnlockTexture takes 100-500ms depending
on the size of the texture. The texture creation, SDL_TextureLock and
the actual data copy is below 30ms (which still sounds like an
acceptable number to me).

Is there anything I can do to speed this up?

Currently, I’m create the texture like this:

gt->sdltex = SDL_CreateTexture(mainrenderer,
SDL_PIXELFORMAT_ABGR8888, SDL_TEXTUREACCESS_STREAMING,
gt->width, gt->height);

Should I maybe pick another pixel format to avoid a conversion? If yes,
how can I know at runtime which one will avoid a conversion? Any other
clues on what could be the major time eater here?

Would SDL_UpdateTexture() be any faster?

Regards,
Jonas Thiem

PS: Full code:

uint64_t ts1 = time_GetMilliseconds();
gt->sdltex = SDL_CreateTexture(mainrenderer,
SDL_PIXELFORMAT_ABGR8888, SDL_TEXTUREACCESS_STREAMING,
gt->width, gt->height);
if (!gt->sdltex) {
    graphicstexture_Destroy(gt);
    return NULL;
}
uint64_t ts2 = time_GetMilliseconds();

// lock texture
void* pixels; int pitch;
if (SDL_LockTexture(gt->sdltex, NULL, &pixels, &pitch) != 0) {
    graphicstexture_Destroy(gt);
    return NULL;
}
uint64_t ts3 = time_GetMilliseconds();

// copy pixels into texture
memcpy(pixels, data, gt->width * gt->height * 4);
// FIXME: we probably need to handle pitch here??

uint64_t ts4 = time_GetMilliseconds();

// unlock texture
SDL_UnlockTexture(gt->sdltex);

uint64_t ts5 = time_GetMilliseconds();
if (ts5-ts1 > 100) {
    printwarning("[sdltex] long texture upload: %dms total, "
        "%dms creation, %dms lock, %dms copy, %dms unlock",
        (int)(ts5-ts1), (int)(ts2-ts1), (int)(ts3-ts2),
        (int)(ts4-ts3), (int)(ts5-ts4));
}

(unlock number is 100-500ms, all the others sum up to less than 30ms)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJS46SRAAoJEBIDTbbx8YkedkMP/j55mvV20eyUwW1OK55Ms0O8
gAVvjmitZywcPAcoaHGnnflS35Kd39OG0FQDX53QrJmsc78haRs7mf9gbakiOwiY
hQONApttyu8lNOmwDKyU9CaR8BeqmJ+6Ni035OK5VwmZbMp3aaL5VAtOUWlWNRnH
OoOPpKmO1qy3HleEoFjjaZweD0h3Sp7EXmS96j0DeVOx4RP56kMwtYMRzL3wCBdp
IDSHjLhZbVdl6tyc/8xXEy95JdzU+qo+oijr4wEIZjIGFapoRXukMAcRVW/WHvGl
ONlhaNSy/88zOjGVsxhyFnvCM7mkLJI18a5CnazWKlywJC8+9OYMtfAw0h3H4yKj
v3+j5AQ8tKw5P+UkuJYxjRls/p7+h/+YL1oL+qZXJzhIKtiPwNx2FHxGSh8aZPoU
v2D9yAgCblKEVtmF7v3/zc4b4uLSfiy7ztLMZYVcyJNrjX1snDFlhwBaw/GwWGe9
OmTdTQ4fVuZyNg+En1xajkvFdudgOyFKsUoj7lLMGAZNA8y21o1V8f/uU3PZuZmO
nboGB1gZ2hAr9n9VcVcPaSZ4H0zm/6LkJjVHdqq+Fm9BDQs90qiDqSgKsDfLeb2p
iTiOUQ/eI3UyHR6O0EwQ29yYHs8q+QTKJyp6CuC7/ReOAUfl2xWfx0m4UrO8G5bt
+8gIIdjuDHCmxalVuP11
=4Ih7
-----END PGP SIGNATURE-----

3

This is how it works with the OpenGL backend:
When you call ‘LockTexture’, SDL gives you a pointer to a backbuffer in
RAM. Then,
when you’re done manipulating that memory region and call ‘UnlockTexture’,
SDL
uploads this backbuffer to the graphics card. Obviously, this will be a
major time
eater. Try manually allocating a back buffer yourself, and then calling
’UpdateTexture’,
and test if the performance is similar.

6

Just how big a texture are you trying to upload? What pixel format are you
using?

2014/1/25 Jonas Thiem > -----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Can I manually allocate one without actually using OpenGL? I’m purely
using SDL textures/SDL accelerated 2d renderer api in my program.

And should it be THAT slow? It’s only a single image.

Would make NPOT textures make this slower? (as in, does SDL reallocate
and then copy it around to add padding to make it a power of two?)

On 01/25/2014 01:18 PM, Jonas Kulla wrote:

This is how it works with the OpenGL backend: When you call
’LockTexture’, SDL gives you a pointer to a backbuffer in RAM.
Then, when you’re done manipulating that memory region and call
’UnlockTexture’, SDL uploads this backbuffer to the graphics card.
Obviously, this will be a major time eater. Try manually allocating
a back buffer yourself, and then calling ‘UpdateTexture’, and test
if the performance is similar.

_______________________________________________ SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJS480zAAoJEBIDTbbx8YkehJ4QAK7cfcNQyPaSwJyQ8sMwtzoM
uLL6Y/2LuYJsDfqmwfioAOum9jYUfxPkE7SdMX/91ex48uaka48eln6D+f9n0SMq
2/XUp4qSMDlU5F16wefnvHLtaZPoweVob8VKeN2+4W60QDCf93c0PEQmd9aB2aqZ
Mgb7qW4HG1urem0AS5XJd+At5ySO6hngsvaHAOYvI5vTqb8uGMqyRiozi8/tYJRt
RiXbZbs2124Qc1f0yq4JJfIh5ttZN2hxKx61U8k+bwIXb40e+c+R3xlRM7Z121Vr
49XeheAa9QEq+jU1C5BOfRVjyXI+WD+4RxCAIADmDCjgJdLbbDiWWYlG/A+d+c4R
npYSNlE4CXm+YsK78c3A/YyegdvdaRteYud78xVwZ2dmIGZeDhaK1DdSJ4UAaCRI
k3a6XKn0zNK0+cBYcq6zKaV8zwAX8uWybtEmpwnlcN7DkkcM0ypUL2jfTdEhW/6D
ZI6K9odQ8UFCWsM1TDPV50RsCvHBEXXyuAzb9IWtWclaRzwKpGgE2G9BEjivsSLh
d2OIebCQwkGPijTwDusH0heAqQJVj2qsw2iQ3Au8Kc+Hurkon3aF+wXUeE7/no2X
yIeW3psfhItBZHxN2sH25J9pihkIT3ZKxl+KdmbY3ggs+RnxdrynuBA33qdaSL7O
29f7XMzC6h2fhiJyTiMV
=058R
-----END PGP SIGNATURE-----

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

7

2014-01-25 Jonas Thiem

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can I manually allocate one without actually using OpenGL? I’m purely
using SDL textures/SDL accelerated 2d renderer api in my program.

Backbuffer = malloc’d RAM, that’s it :smiley:
I see you already have a buffer with your pixel data present (‘data’) that
you
memcpy from. Just use ‘SDL_UpdateTexture’ with that.

And should it be THAT slow? It’s only a single image.

Yeah… that sounds very slow (if it’s just a small image). Again, try and
see
if manually updating results in the same numbers.

Would make NPOT textures make this slower? (as in, does SDL reallocate
and then copy it around to add padding to make it a power of two?)

I think if rectangle textures are available, SDL will use them.