problem with texture memory leak

Audio and Graphics
#1

Hi,

I seem to eat texture memory when I try to determine the number of pixels text would occupy, via the code below.  Note that I remove the text object immediately.

I call:

ss_get_text_width (“hi there”, 20)

and

system.getInfo (“textureMemoryUsed”)

before and after, and see that the delta is about 13 KB (on Android) or 5 KB (on simulator). 

The loss seems 100% reliable.  I tried doing the call 100 times, and lost the same amount each time.

And, calls to “collectgarbage ()” have no effect on this :frowning:

(I.e., the texture memory use does not go down after a garbage collection.)

What am I overlooking?

I’m overly paranoid here, because I don’t (*currently*) don’t intend to call this routine more than a few dozen times at startup (while dynamically sizing some UI items on my screen), but … I don’t like losing memory :slight_smile:

Is there a better way to dynamically determine how much room a newText object will take on the screen?

thanks,

Stan

----------------------------------------------------------------- function ss\_get\_text\_width (s, fsize) -- returns # pixels text would occupy (width, height) local t\_dummy local height = 0 local width = 0 if fsize then t\_dummy = display.newText ({text = s, x = 1, y = 1, fsize = fsize} ) else t\_dummy = display.newText ({text = s, x = 1, y = 1} ) end if t\_dummy then width, height = t\_dummy.width, t\_dummy.height --display.remove (t\_dummy) t\_dummy:removeSelf () t\_dummy = nil end return width, height end -- ss\_get\_text\_width proc
#2

There is no memory leak if you remove the display objects and set them to nil properly, like you seem to be doing with your code.

Are you calling for garbage collection before you try to get the texture memory used? If you aren’t, then it’ll take some time before garbage collection is triggered and so the textures will remain in memory for a while.

You can see how it is done with the code below:

local t = {} local iterations = 100 local delay = 20 local function add() t[#t+1] = display.newText( "Yay", math.random(0, display.actualContentWidth), math.random(0, display.actualContentHeight), nil, math.random(30,120) ) end local function remove() display.remove( t[#t] ) t[#t] = nil end timer.performWithDelay( delay, add, iterations ) timer.performWithDelay( delay\*iterations+50, function() timer.performWithDelay( delay, remove, iterations ) end ) local function checkMemory() collectgarbage( "collect" ) local memUsage\_str = string.format( "MEMORY = %.3f KB", collectgarbage( "count" ) ) print( memUsage\_str, "TEXTURE = "..(system.getInfo("textureMemoryUsed") / (1024 \* 1024) ) ) end timer.performWithDelay( 100, checkMemory, 0 )
#3

Thanks, @XeduR @Spyric ,

your reply inspired me to do more testing.

I hadn’t realized that texture memory garbage collection didn’t happen on demand.  Instead, it seems to happen at the

end (or start) of a frame (and, perhaps, when needed).  Thus, your performwithdelay (or, in my later testing, the wait between tap events) provides the opportunity for texture mem garbage collection. 

I tied a button to my test code, and generally noticed no growth of texture memory as I tapped it repeatedly

(there were some anomalies, but they eventually cancelled out).

TL;DR: I can use my ss_get_text_width routine without worrying about texture memory leaks.

thanks again,

Stan