Leonardi already described the point of multitreaded image manipulation. Thanks for that!
But I need to give you some more precise answers…
I get the point of usage the past tense. DevIL is not being updated for some time, but is certainly offers various types of image manipulation routines: loading, saving, compression, transformation (alienifyng, blurring contrast changing, equalizing,…), etc.
Currently just the two operations: decompression and re-compression.
[QUOTE=Alfonse Reinheart;1244371]
I don’t see how that makes it thread-safe. Wrapping DevIL calls in a singleton does nothing to stop you from calling into that singleton from multiple threads. [/QUOTE]
The mentioned singleton would be used as a context, and by using critical section would make each operation an atomic. But whatsoever, it is not a good idea since, as Leonardi said, it would serialize the whole process.
[QUOTE=Alfonse Reinheart;1244371]
A bigger question might be why you need multithreaded image loading.[/QUOTE]
Well, that’s a really bigger question. Uploading textures to a GPU is a very time consuming task. First, textures have to be read from the disk, or DVD, or downloaded form the net, which is the most time consuming operation (if we neglect caching for a while). Second, downloaded images are not GPU friendly. They are usually stored as JPEG or in some other format, which gives much better compression rate than DXT or other GPU-friendly schemes. Third, in order to increase access speed, there is some kind of RAM-cache. That cache should use some priority/LOD policy for the texture retrieval. All those tasks can be organized in a pipeline form to make use of multiple cores on a CPU and hide the latency. J.M.P van Waveren refers to it as “threaded pipeline” in his “Real-Time Texture Streaming & Decompression”. I had to extend his scheme by adding “an intelligent cache” with infinite number of priorities and self-organizing request queues. So I have a deeper pipeline. But, to make things worse, I have multiple independent data-sources. Making an intelligent cache for multiple sources is very hard to code. So, there are multiple pipelines (one for each storage/data_path). Of course, they are not all active at the same time, but nothing prevents simultaneous activity.
In such environment DevIL cannot be used. Yesterday I made a short overview of available image libraries, and it seams that std_image will be the best suite for jpg/png formats. Other will be treated differently. The only drawback is an inability to handle 16-bit-per-channel images. Luckily, they are rare.