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

[Pierre Lamot]

> I don't understand why you'd need another openGL context if your libvlc 
> user provides one. Why not use the one given by the user?

It is a context created and given by the user, in my patch you use a callback to enter/leave 
this context. My point was, that we needed a dedicated context to be able to render video
within a thread at our own pace.

> > 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..
> 
> That's my problem, why would you need to synchronize two openGL 
> contexts, don't you just need a callback for the core to notify you that 
> the texture is ready (equivalent to vmem-unlock).

I didn't impose anything, if you look at the sample I provide, the synchronisation is made on client side. 
It is just that if you use texture between two threads without synchronisation you're probably going to 
have bad times (tearing for instance).

If  your willing to render you opengl scene at video rate, you can probably achieve this with a single context, 
using vlc callbacks to draw the rest of the scene.

> And maybe one to notify that you should display the function 
> (equivalent to the vmem-display callback).
> 

In my original patch I proposed to have a pre/post rendering callback, which would be 
analogous to the vmem-lock/vmem-unlock. 

> That was my point actually. Sorry if that wasn't clear :)
> You need a callback to require a texture from the libvlc user 
> (equivalent to the vmem-lock)

Actually we don't require to render to a texture, we can render to any framebuffer 
setup by the user.

--
Pierre Lamot