Bump to libavif 1.1.1

[madebr]

Fixes #740

[sezero]

Also bump aom to latest revision of v3.6.1-SDL

[sezero]

P.S: Can you do the same for SDL2_image?

[sezero]

P.S.: Does libavif properly find and use our vendored sharpyuv ?

[madebr]

P.S.: Does libavif properly find and use our vendored sharpyuv ?

It didn't at first, but now it does.

[sezero]

I think this P/R (and its SDL2 counterpart) are ready for merge.

I generated x86 and x64 libavif dlls, run-tested under win11-x64.

One thing I noticed is the possible winpthreads dll dependency
in new libavif: If you think that it's no issue or can be handled later,
then feel free to merge both of the P/Rs: I'll update VisualStudio
and Xcode project files after that.

[madebr]

If you're talking about libsdl-org/libavif@3567afd, it's only added for non-Windows platforms.
Oh no, mingw too.
I think we can remove it?

[sezero]

Oh no, mingw too.

Yup :)

I think we can remove it?

I guess so. I built my dlls w/o removing it, but my toolchains don't have winpthreads.

[sezero]

I think we can remove it?

I guess so. I built my dlls w/o removing it, but my toolchains don't have winpthreads.

Maybe we can guard THREADS_PREFER_PTHREAD_FLAG with NOT MINGW ?

[madebr]

I think we can remove it?

I guess so. I built my dlls w/o removing it, but my toolchains don't have winpthreads.

Maybe we can guard THREADS_PREFER_PTHREAD_FLAG with NOT MINGW ?

I see this in src/format.c:

#if defined(_WIN32)
    tdata->thread = (HANDLE)_beginthreadex(/*security=*/NULL,
                                           /*stack_size=*/0,
                                           &avifImageYUVToRGBThreadWorker,
                                           tdata,
                                           /*initflag=*/0,
                                           /*thrdaddr=*/NULL);
    return tdata->thread != NULL;
#else
    // TODO: Set the thread name for ease of debugging.
    return pthread_create(&tdata->thread, NULL, &avifImageYUVToRGBThreadWorker, tdata) == 0;
#endif

On MSVC and MINGW, it uses _beginthreadex instead of pthreads. Perhaps pthreads is only needed on non-Windows?

[sezero]

Perhaps pthreads is only needed on non-Windows?

Sounds like it

[sezero]

Commenting out OR MINGW works for me (build tested not under SDL_image
but as stand-alone against system libraries.)

--- CMakeLists.txt~
+++ CMakeLists.txt
@@ -613,4 +613,4 @@
-if(UNIX OR MINGW)
+if(UNIX) # OR MINGW
     # Find out if we have threading available
     set(THREADS_PREFER_PTHREAD_FLAG ON)
     find_package(Threads)

[slouken]

Commenting out OR MINGW works for me (build tested not under SDL_image but as stand-alone against system libraries.)

--- CMakeLists.txt~
+++ CMakeLists.txt
@@ -613,4 +613,4 @@
-if(UNIX OR MINGW)
+if(UNIX) # OR MINGW
     # Find out if we have threading available
     set(THREADS_PREFER_PTHREAD_FLAG ON)
     find_package(Threads)

Does it have an alternate Win32 threading implementation? Otherwise this will be a performance regression (assuming previous builds had threading)

[sezero]

Does it have an alternate Win32 threading implementation?

Yes (see reformat.c)

Otherwise this will be a performance regression (assuming previous builds had threading)

Previous version was the same. It is some unfothpmable that that MINGW+pthread check
went into their cmake'ry.

[sezero]

I updated libavif cmake'ry and also updated the Xcode project file along the way. (Did the same in SDL2 version.)

Will merge when the CI is all green.

[madebr]

Thanks sezero for taking care of this

[slouken]

Does it have an alternate Win32 threading implementation?

Yes (see reformat.c)

Otherwise this will be a performance regression (assuming previous builds had threading)

Previous version was the same. It is some unfothpmable that that MINGW+pthread check went into their cmake'ry.

Got it, thanks for clarifying.