Check possibility for decoder/thread reuse

[stitch3210]

First-off - very cool plugin, works off the bat and I like how well it automatically blends in with the Qt image system.

But I found it to be fairly slow.
I noticed in the debugger, that for every image being loaded, 20 threads get launched and then exit again, which seems to me an unnecessary overhead, that may cost more time than it speeds up.
20 threads is the number of logical CPUs on my PC, so that's a match.

The problem is, that Qt will create and destroy an instance of the image handler for each and every picture loaded.

So I wonder, if it shouldn't be possible to create a single, static instance of the avifDecoder and have it keep the threads throughout runtime.
From the libavif explanation of maxThreads, I can't tell how much the avif decoder will actually benefit from multiple threads, if at all. The main use seems to be to parallelize multiple images, which doesn't happen anyway in this current use-case.

[novomesk]

Single/shared decoder instance would be a problem for animations, where the decoder exists for a longer period of time. Threads are created and destroyed by embedded libraries, I guess that re-using the instance is not going to make desired difference.

In my benchmarks on Linux, lossy-compressed AVIF often decodes faster than traditional JPG.

Performance highly depends on how libavif is built. The best performance is achieved when dav1d decoder is available and libyuv is present too.

Maximum thread limis is 64, you may lower the limit in the source.

[stitch3210]

Yes, that's sort of my point.
Your implementation probably doesn't benefit from multiple threads at all, but creates a sh*tload of them.

My scenario: I load around 100 images at once, give or take (and partially in parallel), so a total of 2000 threads are being created and terminated, 1900 of which are then discarded without ever having burned any fuel.
It seems, that when I limit maxThreads to 1 or 2, performance is best (2 seemed slightly - ever so slightly faster, but that may have been coincidence).
So I assume decoding individual images happens in a single thread anyway. There's no point in having the system puke up up to 64 threads over and over again, that will not ever be used.

My concern was basically regarding the overall overhead, not only the threads. Whether having an instance of the decoder up and running instead of loading, initializing, allocating threads, ... for every single image.