Thread Safe Image loading library?
Author
Anyone know of a thread safe image loading library? Ive been using Devil for quite a long time, but it is not thread safe and crashes,loads incorrectly when i use it in more than 1 thread.
NexgenIPL
If you cannot dowload from there, I downloaded it from this URL.
http://mitglied.lycos.de/Binary_Technologies/files/btnexgenipl-2.8.3.zip
You can try this, although I am not sure about the thread saftey. You may need to show your code if you have multi-threading problems. I'm sure there is a way to use DevIL or Nexgen in multi-threaded software.
If you cannot dowload from there, I downloaded it from this URL.
http://mitglied.lycos.de/Binary_Technologies/files/btnexgenipl-2.8.3.zip
You can try this, although I am not sure about the thread saftey. You may need to show your code if you have multi-threading problems. I'm sure there is a way to use DevIL or Nexgen in multi-threaded software.
Author
I dont think Devil supports multi-threading.
It's use of ilBind(), shows that it can only operate on 1 image at a time.
The picture on the left shows how the texture looks "sometimes" when being loaded in another thread. On the right is how it looks when loaded right. If i switch to single threaded loading(load 1 texture at a time), it always looks right.
It's use of ilBind(), shows that it can only operate on 1 image at a time.
The picture on the left shows how the texture looks "sometimes" when being loaded in another thread. On the right is how it looks when loaded right. If i switch to single threaded loading(load 1 texture at a time), it always looks right.
What's wrong with just wrapping a critical section around the entry points to DevIL? You're going to be bound on disk I/O for most of the loading, anyway, which you can do outside of the critical section; the actual decoding is typically much faster than the disk.
Also: it's a bad idea to try to attempt to use graphics APIs from multiple threads. Yes, it MAY work. No, it's not a case that's often optimized. Yes, it may have bugs in various drivers.
Also: it's a bad idea to try to attempt to use graphics APIs from multiple threads. Yes, it MAY work. No, it's not a case that's often optimized. Yes, it may have bugs in various drivers.
Author
The problem is all the file I/O is handled by Devil itself, I could do the file IO myself and pass Devil a pointer to the memory. That is a good suggestion, i will consider doing it.
Also im am not using OpenGL calls in more than 1 thread. My reason for loading in multiple threads is because i wish to do streaming of geometry/textures ala Dungeon Siege.
psuedo-code
//All load in another thread and return immediately
loadTexture("1.jpg");
loadTexture("2.jpg");
loadTexture("3.jpg");
loadTexture("4.jpg");
//Continue rendering as normal
if(loaded("1.jpg"))
{
upLoadtoGL();
}
This way, i can continue rendering while loading textures in the background without a load screen.
Also im am not using OpenGL calls in more than 1 thread. My reason for loading in multiple threads is because i wish to do streaming of geometry/textures ala Dungeon Siege.
psuedo-code
//All load in another thread and return immediately
loadTexture("1.jpg");
loadTexture("2.jpg");
loadTexture("3.jpg");
loadTexture("4.jpg");
//Continue rendering as normal
if(loaded("1.jpg"))
{
upLoadtoGL();
}
This way, i can continue rendering while loading textures in the background without a load screen.
give GTL a wirl and see if that works?
It SHOULD be re-entrant, however I've not tested it for MT compatibilty yet.
note:
C++ library.
Needs a decent compiler and only has builds for VS.Net03 and VS2005(+EE).
oh and requires at reasonably new buikd of Boost, but frankly if you are a C++ programmer you should have this anyways..
Oh, and early next year the interface is going to change slightly (see my journal for details).
[Edited by - phantom on December 31, 2005 7:16:32 PM]
It SHOULD be re-entrant, however I've not tested it for MT compatibilty yet.
note:
C++ library.
Needs a decent compiler and only has builds for VS.Net03 and VS2005(+EE).
oh and requires at reasonably new buikd of Boost, but frankly if you are a C++ programmer you should have this anyways..
Oh, and early next year the interface is going to change slightly (see my journal for details).
[Edited by - phantom on December 31, 2005 7:16:32 PM]
You could have a separate texture loading thread that is the only thread that ever accesses DevIL for file IO. Not sure if you could still have concurrency problems with the rest of DevIL though.
Author
Quote:Original post by T1Oracle
You could have a separate texture loading thread that is the only thread that ever accesses DevIL for file IO. Not sure if you could still have concurrency problems with the rest of DevIL though.
Then i would have to come up with a que and only 1 texture could be actively loaded at any 1 time. But this should work without blocking the main thread.
GTL looks interesting but i need it to be cross-platform to atleast Linux and MacOSX.
Currently im trying to do my own loading using libpng and libjpeg. Ive gotten libpng to work and i don't seem to have any problems yet. Still trying to get libjpeg to work. Also i realise libjpeg has not been updated for 7 years, i wonder if the format has changed in any way over the years.
Quote:Original post by GamerSg
GTL looks interesting but i need it to be cross-platform to atleast Linux and MacOSX.
Fair play, in theory it should just be a matter of someone slapping together a build of it for those two OSes, I'm certain I havent used any platform dependant code anywhere in the lib its self.
As for libjpeg, what problems are you having? GTL uses it internally for JPG loading so you could take a shifty at the source to see how its done. The JPG format its self hasnt changed at all.
On a small aside, you probably only want to do disk I/O in one thread at a time. Reading multiple files at the same time actually causes a performance hit if they take a significant time to read because the OS reads them alternately to keep both threads/processes going (at least that's how I think it works; performance benchmarks I've seen bear out that reading two files gives a smaller transfer rate than reading one).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
