We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Never have got this before. Sketch stops after 1000's of iterations in draw loop at a img=loadImage("c:/avssmth/smthimg.png"); statement. This loadImage is in a If statement , the condition only happens 4-5 times each draw loop so that should not be the problem. Are there requirements to unload to free memory back up for subsequent statements that use memory?
Answers
In general, if at all possible, don't use
loadImage()
in draw. Use it insetup()
.setup()
, load your images once into img / img2 / img3 or into PImage[] images.draw()
reference them as many times as you like in your draw loop -- referencing them will not allocate new memory, because you aren't uselessly creating and destroying objects for the samesmthimg.png
many times per second.Not possible for my application. I create PImage img in setup. But my draw loop calls a outside utility to grab new image to a .png file. Then I load the img with loadImage() in draw loop and display. Is there something I can do to insure loadImage does not leave memory behind when called multiple times ?
I good way to start is providing a minimum example reproducing the problem. If people can reproduce it, they will toss ideas around...
Kf
Hmm. I'm not sure. Here is how loadImage works:
https://github.com/processing/processing/blob/e83ae2054a3d3c52b1663385673fdfb26abcc96b/core/src/processing/core/PApplet.java#L5360
...and it uses ImageIO:
I wonder if using an array of five image objects in your draw loop would help the garbage collector keep up with all the orphans.
the problem doesn't happen until 100's of loops of draw successfully working. So its hard to code a minimum example that actually exhibits the problem. I have found numerous occasions where a small test program i use to learn how things work in Processing often has problems when incorporated into a larger Processing application. Particularly when it has to do with loading files or images. I have a sketch now that runs over 22000 times in the same draw loop and then generates a file missing or inaccessible error! After numerous attempts to solve it seems it is a timing issue as to when the files is completely written and when loadImage "sees" it. Adding a delay worked at first , but when run over and over occassionally after 1000's of loops it generates a file missing error! If i increase the delay time it takes longer to happen, but a delay of 1000, a second is unacceptable. And the check for the file exists is not enough. So i continue to find a workaround. Possibly catching the error and retrying the loadImage till it works? But can't find what exception class to use!
A simple change to a string to add dots to show progress inside the loop is the only change and when run now generates out of memory error after 3500 iterations in draw. Perplexing and I feel like there are a lot of "conditions" i am discovering that need work arounds of some kind to make Processing work. I have programmed in C for over 20 years and never had problems like this. Once something works, adding another function or minor changes in code didn't cause programs not to run unless somthing was wrong with the added code which once debugged solved the problem. But loadImage can work and then after 3000 calls cause an error!
It sounds like print / println might be the culprit here:
the long-standing println bug was apparently fixed in 3.3.4
no using any println, progress is shown by text to screen of string as dots added to string. string is reset to "." at start of each loop.
Is there a way for me to chk how much memory the sketch is using and put up a CLOSE AND REOPEN message to the user periodically before the OOM erro ocurrs as a patch for the problem?
ok so I chk memory at start of sketch with
then i write this info to a .txt file at end of every loop and see what it is when the sketch gives out of memory
At start I get : max=915 free=61 %=42 when it stops the last numbers written to the file are: max=849 free=65 %=35
Shouldn't these indicate a out of memory approaching?
What number would be the one to signal running out of memory?
So the Java garbage collection and memory management works in the background . In post from 2016 from Henri , "PImage won't release memopry" KevinWorkman says the Java garbage collection and memory management works in the background so "Out of Memory" error should never happen. Wonder if it is fixed in later versions or what cause I get it in the following scenerio.
Continued: https://forum.processing.org/two/discussion/27810/out-of-memory-error-on-loadimage-in-draw-loop