Add SDL_CreateTexture from some shared texture

[1bsyl]

There was this feature for the camera API, where the device can provide an handle to manipulate texture with 0-copy, which must faster that getting a software surface (#8565 ).

Same way we grab a software frame with
SDL_Surface * SDL_AcquireCameraFrame(...);,
we could introduce a new type (ok whatever), SDL_0CopyTexturem and have a similar API:
SDL_0CopyTexture * SDL_AcquireCamera0CopyFrame(...)

we would also need the correct helper functions
SDL_Create0CopyTextureFrom() .. (does this has to be from something here ?)
SDL_UpdateTextureFrom0Copy()

The use-case here the camera api, but I thing this can more generic purpose.

[slouken]

0-copy textures are created using properties to specify the platform specific details. I'm not sure how this integrates into the camera system, but you can see an example of this in testffmpeg.

[1bsyl]

SDL_Create0CopyTexture() could hide all those platform specific details.

Looking at testffmpeg:

GetTextureForMemoryFrame is the usual way:
call SDL_CreateTexture() once and then SDL_UpdateTexture(), sending the new software buffer for each new memory frame.

but GetOESTextureForDRMFrame recreates the SDL_Texture each time and update it from the fd handle.
it could be splitted the same way: Create0CopyTexture once(), then and Update0CopyFromHande()
(this handle is dmabuf for v4l2 or clientbuffer in android, anyway something to hide)

the update part:
https://github.com/libsdl-org/SDL/blob/main/test/testffmpeg.c#L840
is similar to the camera 0copy:
https://github.com/libsdl-org/SDL/pull/8565/files#diff-a9717185365da787cba4e3193430078ff78313a64f1898ca7f66d1f18153f28eR323

It seems this could be factorized.

but maybe 0 copy texture need to much customization and not obvious to abstract it. And maybe re-creating the texture isn´t a big deal.

Since the use-case I thought was the camera API, maybe it can simply turned into adding a SDL_Texture * SDL_AcquireCameraFrame(SDL_Renderer *, ...); that would create a 0copy texture and avoid the software copies.

[1bsyl]

so if creating a re-creating 0copy texture each frame isn't a big deal. (vs only updating a 0copy texture, each frame), then this is ok. and I´ve clarified what I thought so closing this ticked, and re-opened a new one for the camera with the suggestion !

[1bsyl]

one more guess:
if we ever add SDL_Texture * SDL_AcquireCameraFrame(SDL_Renderer *, ...)
can the camera backend buffer enough SDL_0CopyTextures ??
or really, should it queue some 0CopyHandle instead ?

[slouken]

Duplicate of #9826