Do I need SDL_LockTexture()?

I was wondering whether it is necessary to use SDL_LockTexture() and SDL_UnlockTexture() when drawing pixels directly with SDL_TEXTUREACCESS_STREAMING. I can seem to draw pixels just fine without them. Is it bad that I don’t use them?

The problems will begin once you’ll start using multiple threads.
Oh, and SDL might sneak up a thread on you.
Better properly lock and unlock.On 13 February 2014 13:07, dandago wrote:

I was wondering whether it is necessary to use SDL_LockTexture() and
SDL_UnlockTexture() when drawing pixels directly with
SDL_TEXTUREACCESS_STREAMING. I can seem to draw pixels just fine without
them. Is it bad that I don’t use them?


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

You didn’t say how you modify the texture’s pixels.

I believe that it is only necessary to call SDL_LockTexture() and SDL_UnlockTexture() if you want to
directly manipulate the texture’s pixels (i.e. SDL_LockTexture retrieves the pointer to the
texture’s pixels).

If the pixels are in a separate buffer (e.g. array), then you can call SDL_UpdateTexture() instead.
This will copy the the separate buffer’s pixels into the texture’s pixel buffer. Someone will
correct me if I am mistaken.

Cheers,

AlvinOn 13/02/14 07:07, dandago wrote:

I was wondering whether it is necessary to use SDL_LockTexture() and SDL_UnlockTexture() when
drawing pixels directly with SDL_TEXTUREACCESS_STREAMING. I can seem to draw pixels just fine
without them. Is it bad that I don’t use them?

[snip]

I’m using a separate buffer and then SDL_UpdateTexture(). Do I still need to lock/unlock?

I’m not using any multithreading at the moment, so if that’s the issue, then I suppose I don’t need any locking/unlocking.

@Ivan Rubinson, what do you mean by “SDL might sneak up a thread on you”?

I mean that nothing prevents SDL from creating a thread without telling you
and trying to do something with your texture.
It’s an implementation detail.On 13 February 2014 15:49, dandago wrote:

I’m using a separate buffer and then SDL_UpdateTexture(). Do I still
need to lock/unlock?

I’m not using any multithreading at the moment, so if that’s the issue,
then I suppose I don’t need any locking/unlocking.

@Ivan Rubinson, what do you mean by “SDL might sneak up a thread on you”?


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

I’m using a separate buffer and then SDL_UpdateTexture(). Do I still
need to lock/unlock?

I’m not using any multithreading at the moment, so if that’s the issue,
then I suppose I don’t need any locking/unlocking.

If you are using a separate buffer and SDL_UpdateTexture() your textures DO
NOT need to have streaming access, and you do not need lock/unlock them.

If you enable streaming textures SDL will create a back buffer for you,
you’ll then have to use LockTexture to get a pointer to the back buffer,
and UnlockTexture to upload the backbuffer to the GPU texture.

Please note that we are still strictly single thread,
SDL_Lock/UnlockTexture is not a mutex that allows you to use the SDL
rendering API in a multithread way. Except when explicitly written in the
documentation (eg. SDL_PushEvent ), SDL calls are NOT thread safe and
should be all performed on the thread that created the window/renderer.On Thu, Feb 13, 2014 at 2:49 PM, dandago wrote:


Bye,
Gabry

It seems you’re right, I can get along just fine with SDL_TEXTUREACCESS_STATIC. But even with SDL_TEXTUREACCESS_STREAMING, it works just fine if I don’t lock. I’m creating the texture like this:

Code:
SDL_Texture * texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STREAMING, 320, 168);

…and this is my game loop:

Code:

while (!quit)
{
	SDL_UpdateTexture(texture, NULL, &pixels, 320 * sizeof(Uint32));
	SDL_WaitEvent(&event);

	switch (event.type)
	{
	case SDL_QUIT:
		quit = true;
		break;
	}

	SDL_RenderClear(renderer);
	SDL_RenderCopy(renderer, texture, NULL, NULL);
	SDL_RenderPresent(renderer);
}

I’d just like to know whether what I’m doing is wrong, vis-a-vis locking (since I’m NOT locking anything).

What I think you mean is that you’re supposed to lock the texture with streaming access, get a pointer to the back buffer via the pixels parameter, do your pixel operations and compositing there, and unlock to send the data back to video memory. On the other hand static access is okay when you just want to throw a set of pixels onto video memory all at once. But if this understanding of mine is correct, it still leaves an ambiguity: why am I still allowed to upload pixels with streaming access as I would with static access (as in the above code)?

What you’re doing is ok. Streaming texture can be used everywhere a
static texture can be used. Additionally, you can Lock/Unlock a
streaming texture. Streaming texture will take up extra RAM, so keep
that in mind.On 2/13/2014 9:32 PM, dandago wrote:

It seems you’re right, I can get along just fine with
SDL_TEXTUREACCESS_STATIC. But even with SDL_TEXTUREACCESS_STREAMING,
it works just fine if I don’t lock. I’m creating the texture like this:

Code:
SDL_Texture * texture = SDL_CreateTexture(renderer,
SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STREAMING, 320, 168);

…and this is my game loop:

Code:

while (!quit)
{
SDL_UpdateTexture(texture, NULL, &pixels, 320 * sizeof(Uint32));
SDL_WaitEvent(&event);

  switch (event.type)
  {
  case SDL_QUIT:
     quit = true;
     break;
  }

  SDL_RenderClear(renderer);
  SDL_RenderCopy(renderer, texture, NULL, NULL);
  SDL_RenderPresent(renderer);

}

I’d just like to know whether what I’m doing is wrong, vis-a-vis
locking (since I’m NOT locking anything).

What I think you mean is that you’re supposed to lock the texture with
streaming access, get a pointer to the back buffer via the pixels
parameter, do your pixel operations and compositing there, and unlock
to send the data back to video memory. On the other hand static access
is okay when you just want to throw a set of pixels onto video memory
all at once. But if this understanding of mine is correct, it still
leaves an ambiguity: why am I still allowed to upload pixels with
streaming access as I would with static access (as in the above code)?


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


Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming