[vlc-devel] [PATCH 1/4] vgl: provide a module to allow rendering in a user defined opengl context

[Pierre Lamot]

Hi,

I think we need to let the user define the context and the texture.

VLC will render video in its own OpenGL  thread and at its own rate. 
User will have its scene rendering at (i.e.) 60fps  while we will have video 
rending at (i.e.) 24 fps. So we have two rendering thread and two contexts.
The user one, and VLC one. VLC context need to be shared with user context 
in order to let texture to be usable in both contexts. Shared context need to 
be created from the parent context (user) (see wglShareLists, glXCreateNewContext, 
etc..)

The next problem is the synchronizations between the contexts. User might 
have different use cases: rendering to textures using FBO with triple 
buffering for sync, custom sync using glMemoryBarrier, etc..

We can probably take the texture creation on our side, the user would 
specify a number of texture to allocate, we put them in a queue, render 
to it using an FBO, and delivering it though a callback during the swap
texture being put back in our queue though a callback. User being responsible 
to release the memory and keep the queue un-empty. Probably close from what
you had in mind?

Thought, this mean that users won't have means to customize texture creation,
ie: for mipmap level, or to use opengl extension to create special textures (?)

On samedi 7 juillet 2018 17:49:17 CEST Denis Charmet wrote:
> Hi,
> 
> On 2018-07-04 10:06, Pierre Lamot wrote:
> >> I don't really see why this needs to be exposed here. Virtualized 
> >> plugins
> >> generally call the initialization and deinitialization callbacks 
> >> in-situ.
> > 
> > AFAIK, opengl modules don't have access to the picture size.
> > 
> 
> Excuse my general lack of knowledge over the whole direct rendering 
> pipeline and opengl but would't getting the dimensions of the picture 
> defeat the whole principle of the external context?
> 
> If I may use the vmem analogy wouldn't it make more sense to have the 
> virtualized plugin actually set define its dimensions to VLC and not the 
> way around? If you need an external openGL context, it's usually because 
> it's already externaly constrained.
> 
> Shouldn't you need 1 callback to get a texture id, one to blit it in 
> your backbuffer and one to swap the back and front buffer and finally 
> one to free the texture?
> 
> Regards,
> 

--
Pierre Lamot