Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

problem with texture memory leak
Started by sieler2 Mar 06 2020 10:56 PM

2 replies to this topic
[TOPIC CONTROLS]
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

sieler2

[GLOBAL: userInfoPane.html]
sieler2
  • Contributor

  • 116 posts
  • Corona SDK

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 :(

(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 :)

 

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



[TOPIC: post.html]
#2

XeduR @Spyric

[GLOBAL: userInfoPane.html]
XeduR @Spyric
  • Corona Geek

  • 1,246 posts
  • Corona SDK

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 )

  • sieler2 and pixec like this

[TOPIC: post.html]
#3

sieler2

[GLOBAL: userInfoPane.html]
sieler2
  • Contributor

  • 116 posts
  • Corona SDK

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




[topic_controls]
[/topic_controls]