Add OpenGL texture wrapping mechanism

Analog to the vulkan VkImage interop API

changed milestone to %v2.66+

added enhancement good first issue opengl labels

What we need to provide so far we the interop in VLC are mostly here:

https://code.videolan.org/videolan/vlc/-/blob/master/modules/video_output/opengl/interop.h

The more readable list:

• handle case when npot is not available
• transformation matrix (because of android)

For the filter and display output part, the destination can be a surface or a bounded fbo. I guess we can provide the name to the filter if you want to handle it yourself but it might be hard to provide a finer level of details since it quickly involves platform-specifics points (SurfaceTexture on Android, renderbuffer attached to a drawable on iOS for example).

For NPOT, I think the "correct" way would be to have the pl_tex represent the true texture size and only sample from the "cropped" region via other mechanisms (i.e. pl_image.src_rect when using the renderer API, or pl_sample_src.rect when using the shader API). In theory, we could also add a flag to pl_sample_src like bool clamp_sampled_region; to make it bounds-check texture accesses in the shader code, to prevent the green lines issue you guys mentioned in your comments.

What's the transform matrix used for in practice? Is this about stuff like GL_TEXTURE_RECTANGLE? I know mpv has some code for this, maybe I could steal from that. Would it be possible to simply use this exactly when target == GL_TEXTURE_RECTANGLE, without an extra bool for it? Or is there some other target type that requires a custom transform matrix?

In theory, we could also add a flag to pl_sample_src like bool clamp_sampled_region; to make it bounds-check texture accesses in the shader code, to prevent the green lines issue you guys mentioned in your comments.

Tracking this in #92

Hi

For NPOT, I think the "correct" way would be to have the pl_tex represent the true texture size and only sample from the "cropped" region via other mechanisms

Seems reasonable to me.

What's the transform matrix used for in practice?

Google idiocracy. Basically it handles texture coordinates change for rotation and npot for the user in hello world case, but I don't know whether you have access to it otherwise.

So, looking at the ASurfaceTexture stuff, I think the getTransformMatrix isn't best handled as part of the pl_tex abstraction but also delegated to the "other" components in libplacebo, the ones that deal with actually sampling from sub-regions of the texture.

Although, I am going to handle sampler2DRect etc. as part of pl_tex, so at least the non-normalization parts of the transform will be done by the pl_tex abstraction, conceptually.

mentioned in commit 7ae02666

mentioned in commit 663c8cb3

closed via merge request !98 (merged)