Clarify SDL_Texture life cycle

[bottle2]

specifically, I wanted to know if there is any chance a SDL_Texture to become invalid after a window is resized on Windows 10 using direct3d renderer.

my toy code crashes with SIGSEGV when resizing window, GDB says it happens after calling SDL_DestroyTexture, something-something LocalFree. maybe it is my fault, I'm still debugging. I'm actually using SDL2 on MSYS2, but anyway, it is only useful to improve current documentation.

places this information could be added to:

• https://wiki.libsdl.org/SDL3/SDL_Texture
• https://wiki.libsdl.org/SDL3/SDL_CreateTexture
• https://wiki.libsdl.org/SDL3/SDL_DestroyTexture

[bottle2]

yeah, it stopped crashing after I started to destroy and create texture after every single resize event, even if the window size didn't really change at all. I don't really know the difference between SDL_WINDOWEVENT_RESIZED and SDL_WINDOWEVENT_SIZE_CHANGED, I'm doing texture destroy/create for both events. anyway, I don't ever question working code, so that is it. I still appreciate if documentation is improved in this regard.

[icculus]

Are you also getting a SDL_EVENT_RENDER_TARGETS_RESET, SDL_EVENT_RENDER_DEVICE_RESET, or SDL_EVENT_RENDER_DEVICE_LOST event?

[bottle2]

@icculus

Hey.

I did a short test where I resized my window many times, and I minimized and maximized a couple times, and I closed the lid of my notebook once. SDL_RENDER_TARGETS_RESET was sent 16 times. SDL_RENDER_DEVICE_RESET was not sent at all. SDL_EVENT_RENDER_DEVICE_LOST is not present in SDL2. I doubled checked to make sure I was incrementing and printing the correct variables. The longest burst of such events in a single "frame" was 1.

Reading https://wiki.libsdl.org/SDL2/SDL_EventType requires to all textures to be recreated for SDL_RENDER_DEVICE_RESET. Thus, it would be interesting if the See Also section of all entries regarding textures point to the documentation for these event types. actually, I now remember reading a long time ago https://github.com/libsdl-org/SDL/blob/main/docs/README-android.md and, which also discusses recreating OpenGL and "restoring" textures.

I think that consistent nomenclature is a nice to have. To avoid synonyms such as "recreate", "restore", "regenerate", "updated". Just one jargon.

Thinking about SDL3: https://wiki.libsdl.org/SDL3/SDL_EventType

It says for SDL_EVENT_RENDER_TARGETS_RESET that "The render targets have been reset and their contents need to be updated". I'm writing to locked textures, my renderer always have the NULL "default render target" for SDL_SetRenderTarget. "contents need to be updated" is not clear as well, maybe you could complement "before calling SDL_RenderPresent" or something. I don't know.

Thus, this single line of documentation doesn't seem to suggest about recreating texture.

but you know better!! I don't even know if recreating my textures during this event will stop crashing. I'll test later.

but most importantly. I think the documentation should explain if, upon a device or targets reset, if the existing SDL_Texture pointers become invalid and must not be used, and the user must not destroy them manually; or whether one should call SDL_DestroyTexture for all of them after the reset. this is exactly my paint point of understanding texture life cycle.

[bottle2]

okay, I have no idea how this works. I read here: https://stackoverflow.com/a/78803079
my texture is not created with SDL_TEXTUREACCESS_TARGET. according to this guy, SDL would recreate it on my behalf? but my program is dying when it destroys texture after the window is resized. but hey, I'm using SDL2. maybe it was fixed in SDL3 and I don't know? will I ever know? I'm lost

I think I will write a MRE

[bottle2]

hey @icculus

turns out it was all my fault! I was indexing an array out of bounds. sorry for the wall of text!!

once again I'm fooled by Windows. I run my program with GDB and address and undefined sanitizer, they never caught the root cause of my SIGSEGV. from my slim experience, I guess Windows tries to make wrong programs survive for very long... so when they finally crash, the problem appears in a unrelated place, such as SDL_DestroyTexture.