Hello; I was doing some tests with framebuffers, and i've run into a quite frustrating issue.
Essentially, I'm trying to get the ImageData from a Framebuffer every cycle; after a while, I get a crash. I'm running 0.7.1 on Windows 7 (64 bits). In case it's important, I'm not running LÖVE from an installation.
I get about 960-970 cycles in the attached .love (there's a counter) before the crash. Please check it out if you have the time.
function love.load()
someimage = love.graphics.newImage('someimage.png')
fb = love.graphics.newFramebuffer(800,600)
avariable = 0
end
function love.update()
id = fb:getImageData()
avariable = avariable + 1
end
function love.draw()
love.graphics.setRenderTarget(fb)
love.graphics.draw(someimage,800/2,600/2,0,1,1,someimage:getWidth()/2,someimage:getHeight()/2)
love.graphics.setRenderTarget()
love.graphics.draw(fb,0,0)
love.graphics.print(avariable,10,10)
end
same happened on my computer... after 1001 cycles the program crashes.
In my process manager I could see, that love is eating all of my memory until the crash.
same happened on my computer... after 1001 cycles the program crashes.
In my process manager I could see, that love is eating all of my memory until the crash.
But your code looks fine... maybe the line
id = fb:getImageData()
is critical ??
Yep, it's clearly that function. It's obviously not made for continuous calling, but I don't think the problem is necessarily about memory (I get a steady framerate until the crash). Are you running the windows version too?
thelinx wrote:What OS are you guys running? It runs perfectly well for me on 64-bit Debian.
Windows (mind-parries collective groan) 7, 64-bit for me
Robin wrote:I'm on 64-bit Ubuntu, and for me the system slows down massively in the 1300-1500s, after which I closed LÖVE normally.
Doesn't look like a bottleneck at all on my case (the performance is steady from load to crash), but I do get about 12% memory usage on my manager, when even graphics-intensive .loves usually keep under 10%.
On Ubuntu (32bit) :
At 300, my whole system tend to slow down because of high CPU usage (old centrino 1,2 GHz).
At 500, my 1GB memory begins to be full (yes I have an old, weak, but small laptop) and the swap begins, then CPU usage decreases (it waits from the slow HDD).
Then at 1000, my 2GB swap is almost full I have to kill love (I do not want to crash my computer).
I could test on a better laptop (Quad core i7/Too much RAM to be counted/64 bits and all this ) later if it can help.
When you make a call to fb:getImageData() a new image data is created, which has all pixels from the frame buffer so the memory requirements for it is width*height*bpp (where bpp is probably 4.) But on the Lua side of things what is created is a Proxy userdata, which takes only a handful of bytes and points to the actual image data object.
So the problem is, Lua doesn't see a need to trigger the garbage collection because for it each image data object takes only the size of a Proxy when in fact the each of these proxies point to an image data which takes far more memory. So the RAM is exhausted and eventually the computer begins to swap pages, slows down, and crashes (Windows, Linux will probably do something wiser.)
The need to inform Lua about the total size of an userdata, which in this case would include the size of the image data, comes up in its mailing list from time to time, but it was never added to the API. I don't remember if there's an workaround for that besides always allocating memory through lua_newuserdata and using luaL_ref/unref on them to avoid them being collected when still being pointed to by other objects.
In this specific case, maybe fb:getImageData() could optionally accept an image data parameter the same size of the frame buffer, which would be used to get the frame buffer pixels instead of creating a new image data?
same happened on my computer... after 1001 cycles the program crashes.
In my process manager I could see, that love is eating all of my memory until the crash.
Same for me - at about 1500 I get love crash, and top shows it gets almost 3GB of RAM. Clearly a memory leak somewhere (maybe in underlaying DevIL library).
I am using love-jit on linux 32bit.
) later if it can help.
