On Tue, 13 Jun 2017 15:59:00 +0300 (EEST)
Martin Storsjö <mar...@martin.st> wrote:

> On Tue, 13 Jun 2017, wm4 wrote:
> 
> > On Tue, 13 Jun 2017 15:31:12 +0300
> > Martin Storsjö <mar...@martin.st> wrote:
> >  

> >> +static AVOnce functions_loaded = AV_ONCE_INIT;
> >> +
> >> +static PFN_CREATE_DXGI_FACTORY mCreateDXGIFactory;
> >> +static PFN_D3D11_CREATE_DEVICE createD3D;  
> >
> > I think following a consistent naming convention would be good. I like
> > "m" + real API name.  
> 
> So mD3D11CreateDevice?

Yep.

> >> +
> >> +static av_cold void load_functions(void)
> >> +{
> >> +#if HAVE_LOADLIBRARY  
> >
> > The UWP define wasn't sufficient?  
> 
> It was sufficient, but IMO this condition is simpler (especially for 
> configure). But with CreateDXGIFactory vs CreateDXGIFactory1, having it 
> specific for UWP might be better of course.

I don't really see a need for the LoadLibrary test (in fact it could
succeed on UWP if you have this winstorecompat thing active?), but I'm
not really against it either.

> >> +    // We let these "leak" - this is fine, as unloading has no great 
> >> benefit, and
> >> +    // Windows will mark a DLL as loaded forever if its internal refcount 
> >> overflows
> >> +    // from too many LoadLibrary calls.
> >> +    HANDLE d3dlib, dxgilib;
> >> +
> >> +    d3dlib  = LoadLibrary("d3d11.dll");
> >> +    dxgilib = LoadLibrary("dxgi.dll");
> >> +    if (!d3dlib)
> >> +        return;
> >> +
> >> +    createD3D = (PFN_D3D11_CREATE_DEVICE) GetProcAddress(d3dlib, 
> >> "D3D11CreateDevice");
> >> +    if (dxgilib)
> >> +        mCreateDXGIFactory = (PFN_CREATE_DXGI_FACTORY) 
> >> GetProcAddress(dxgilib, "CreateDXGIFactory");  
> 
> Was this intentional that we should try to continue even if dxgi.dll 
> doesn't exist, in case the device parameter is null? Or was that just 
> coincidental behaviour in the previous form of the code?

There is no reason to fail in that case, but on the other hand it
doesn't matter. If DXGI is unavailable, you're going to have worse
problems.
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to