I got a problem with ofImage loadImage(). I want to load alot of image after eachother, but if i got a ofImage object and call loadImage on it, i’m not guaranteed that it’s loaded before it continues. So if i call many loadImage just after eachother it continues showing the first image in my ofImage.draw(), (until i stop loading images, then it finaly show the newest image). Is there a way where i can be sure that it doesn’t start loading a new image before the old when has shown up?
hmm. to the best of my knowledge loadImage() isn’t multi-threaded, so it will block until the image has loaded.
perhaps you’re doing something else to give you this strange behaviour. can you post the code that does the loading, and the code that does the drawing?
i can see that it correctly calls the load image. But it simply doesnt update the ofImage texture before its done loading the last image. And i want it to show images when im moving the mouse aswell (doesnt have to be all images, but atleast it should load a image when the last one is done)…
It does print correct uris out. So when i move my mouse, it prints alot of uris out (i got alot of images). And when i stop it shows that last uri it has printed. But all the others don’t get shown. But if i move my mouse very slowly it does load the images (and show them). So it must have something to do with not being finished loading before beginning on a new load.
perhaps ofImage needs 1- or 2- updates for the loaded data to propagate through to the actual drawn image?
to test this, try only calling loadImage every second or third time mouseMoved is called. if this solves it, try having two images and swapping between them (load from one but draw from the other, swap each frame), or three images and rotating between them.
there’s another (better) way to do this, though, which is to load in all the images at setup time, and only switch which one you’re drawing at runtime. loading at runtime is always going to lead to performance problems…
perhaps ofImage needs 1- or 2- updates for the loaded data to propagate through to the actual drawn image?
I really doubt this - (more accurate with quicktime, though, where it’s internally threaded). freeImage calls are blocking for sure. I wonder if there isn’t a problem with doing opengl operations in the mouse events (although I am 99.9% sure these are ok). I do think damian’s solution (better) is better
Can you post a zip of the src/data folder that shows the problem?
I solved the problem. The problem is only present if i call loadImg directly from mouseMoved. When i debug, it does call the function (it prints in the console), but if i put a print it to the monitor with a font in the draw method, it does not write it out (which means that draw is’nt called). But by moving the loadImg to the update function it does draw every frame.
So by some way the order of function calling gets screwed up when i call my load image every frame from the mouseMoved!
but if i put a print it to the monitor with a font in the draw method, it does not write it out (which means that draw is’nt called).
note - the main app “draw” function clears the screen at the start, so if you do draw in the mouse function, it will get over written and you wont see anything… you should only draw in “draw”
I have made a simplified version of my program that only does the loading. And it writes it to the console when it loads a new image, and to the screen (in the draw method). When pressing i key it switches the mode of loading, so its pretty easy to see the difference (at least on my macbook with Mac OS X 10.5)
And by the way, i originaly made this in processing, but i had huge problems loading image fast enough (i think it took one second per image almost). And here in oF it can load the same images extremely fast! Thumbs up!