[vlc-devel] [PATCH] video_output: refactor vlc_gl_api into opengl providers

[Alexandre Janniaux]

Hi,

On Mon, Sep 21, 2020 at 02:51:45PM +0200, Thomas Guillem wrote:
>
>
> On Mon, Sep 21, 2020, at 14:29, Alexandre Janniaux wrote:
> > Hi,
> >
> > On Mon, Sep 21, 2020 at 01:15:05PM +0200, Thomas Guillem wrote:
> > > Hello,
> > >
> > >
> > > From what I see, you just moved the vlc_gl_api_Init() call from vout_helper.c to each module. The call was and still is surrounded by ?GLMakeCurrent(). So, I fail to see a difference with this only patch.
> > >
> > > Maybe include the patches (or only one) that depends on this one to show us the big picture.
> >
> > I refer you to the OpenGL Filter RFC I've sent, and the details in the
> > commit message. ;)
> >
> > What this patch does is exactly what you're saying. The MakeCurrent
> > before fetching the symbols is not sexy, but WGL and EGL need it and
> > in general, it's needed to extract some OpenGL properties.
> >
> > The point is that with filters, you need to link each gl API providers
> > with the OpenGL informations, which is very annoying since those are
> > typically filter_t, display and vout_helper code.
> >
> > Instead, this patch suggests to use the building block actually called
> > "OpenGL providers" to provide OpenGL.
> >
> > I hope this is clearer.
>
> What about the gl_api.c .h added in Sources when all modules link already with libvlc_opengl ?
>
> Your commit log say it fixes an issue for Windows, and I fail to see any functional changes that could lead to such fixes.

I could detail the fix for windows in the commit message, sorry.
Basically you have two kinds of OpenGL providers: those having the
core symbols and those that don't.

Windows is in the first categories, but my libvlc_opengl patches
made it like the second category, as the gl_api.c was compiled into
the libvlc_opengl code instead of the wgl and glwin32 modules.

Because of that, wgl tried to load core symbols (like glGenTextures)
and didn't find them, resulting in a loading error.

The state before both this patchset and the previous one was quite
entangled since the OpenGL code as a whole was recompiled for every
display each time, and display needed to match the option we're giving
to the OpenGL implementation with the suggested patch here.

By recompiling everything, you also need different display code for,
for instance, wgl provider and egl_win32 provider, since the last one
is actually in the second category above (ANGLE). so you actually need
pairs of display-opengl providers to make it work.

The former patchset broke the possibilities to do that, and this patch
moves it to the opengl provider so we don't have to worry with the
display anymore.

In the incoming other patches, I add an offscreen opengl API to create
offscreen OpenGL providers, and since the number of OpenGL provider
modules increases because of that, duplicating every modules after in
the chain became completely unmaintainable, hence this patch.

I hope it answers both questions.

Regards,
--
Alexandre Janniaux
Videolabs


> >
> > Regards,
> > --
> > Alexandre Janniaux
> > Videolabs
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel