Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Remove all objects
Started by dellagd Mar 05 2011 08:23 AM

- - - - -
59 replies to this topic
[TOPIC CONTROLS]
Page 2 of 3 1 2 3
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#26

FrankS

[GLOBAL: userInfoPane.html]
FrankS
  • Contributor

  • 219 posts
  • Corona SDK

Well... in a distant past I too have coded a fair amount of perl prose/poetry, and I'm so happy that that particular company went belly-up such that there is not even a remote chance that I'd be asked to debug any of my old scripts ;-)

The interesting fact about those monkey patches is that the one who writes it will easily use it with confidence, while those that have to adopt it are more than weary and suspicious to have it included in any module/library that is loaded...

Now being pragmatic, I am only interested in the consequences of adopting a solution like this, and as I understand it those are:

* this patching of display.newGroup() overwrites the global reference to the original Corona function, it wedges itself in between and all your libraries/modules will use it whether you like it or not (just a clarification to any readers that didn't catch on to that yet)

* this global display.newGroup() patch must be included in the main.lua file before any other module is loaded to be effective and predictable (this will circumvent that competing localizing scenario that I described).

* God or any other higher coding-authority forbid that there is any other module loaded that was written by someone who had the great idea of also patching that same global display.newGroup() - all bets are off what would happen then... (although it could lead to some interesting bugs...;-)

* Ansca should step up to make this issue go away - the idea that many of us would start to rely on this monkey-patching of their core library routines to sidestep memory-leak issues, should make them shiver as it makes future changes/fixes more complicated - Ansca are you reading this? Please engage in these discussions...

-FrankS.
uid: 8093 topic_id: 7489 reply_id: 26865


[TOPIC: post.html]
#27

jonbeebe

[GLOBAL: userInfoPane.html]
jonbeebe
  • Contributor

  • 511 posts
  • Corona SDK

I posted this to my blog, as well as a download to a script that everyone can include in their projects, that provides both solutions proposed by FrankS and p120ph37.

More details and download here:
http://jonbeebe.tumblr.com/post/3760389212/proper-group-cleaning-in-corona-script-download
uid: 7849 topic_id: 7489 reply_id: 27172


[TOPIC: post.html]
#28

FrankS

[GLOBAL: userInfoPane.html]
FrankS
  • Contributor

  • 219 posts
  • Corona SDK

Nice blog entry and thanks for the acknowledgement.

However, I believe that you missed the point in the blog that neither of the solutions nor the combination is the best one, and that only Ansca can (and should) provide an enhanced removeSelf replacement for their Corona-sdk that would benefit everybody all the time tremendously as memory-leaks are about the nastiest critters in your code.

Regards, FrankS.
uid: 8093 topic_id: 7489 reply_id: 27221


[TOPIC: post.html]
#29

p120ph37

[GLOBAL: userInfoPane.html]
p120ph37
  • Enthusiast

  • 46 posts
  • Corona SDK

I appreciate your attempt to credit both FrankS and me, but I think your combination of the two methods is redundant - either one will suffice to clean out a group without the aid of the other, they just take different approaches to it.

Also, you threw in a lot of Scale=0.1 lines without explaining why. I imagine you did that in the hopes of shaking up any image objects enough that the other currently-at-large memory leak might not manifest, but you didn't explain.

Otherwise, nice writeup. :-)
uid: 32962 topic_id: 7489 reply_id: 27236


[TOPIC: post.html]
#30

rickwhy

[GLOBAL: userInfoPane.html]
rickwhy
  • Enthusiast

  • 89 posts
  • Corona SDK

Hey guys!
Looks great
Beebe I can't get the script to work.
When I'm calling cleanGroup I get:
... attempt to call global 'cleanGroup' (a nil value)

What stupid mistake am I'm doing? :)
I'm using it together with director and I'm require before everything else.
uid: 10657 topic_id: 7489 reply_id: 27252


[TOPIC: post.html]
#31

jonbeebe

[GLOBAL: userInfoPane.html]
jonbeebe
  • Contributor

  • 511 posts
  • Corona SDK

@rickwhy: Please download the script again, I updated the download link. In the last module, I accidentally set the cleanGroup function to local out of habit.

You can either download the updated script here: http://cl.ly/58iT

Or you can simply remove 'local' from the cleanGroup() function definition in cleangroup.lua.

Sorry about that! All is fixed now though...
uid: 7849 topic_id: 7489 reply_id: 27254


[TOPIC: post.html]
#32

rickwhy

[GLOBAL: userInfoPane.html]
rickwhy
  • Enthusiast

  • 89 posts
  • Corona SDK

awesome just found that in the other thread :)
thanks
uid: 10657 topic_id: 7489 reply_id: 27255


[TOPIC: post.html]
#33

Andriy Pertsov

[GLOBAL: userInfoPane.html]
Andriy Pertsov
  • Contributor

  • 211 posts
  • Corona SDK

jonbeebe, Thanks for the code.
But why are you scale object to 0.1?
uid: 9058 topic_id: 7489 reply_id: 27258


[TOPIC: post.html]
#34

jonbeebe

[GLOBAL: userInfoPane.html]
jonbeebe
  • Contributor

  • 511 posts
  • Corona SDK

According to this thread:

http://developer.anscamobile.com/forum/2010/12/08/memory-leak-when-removing-and-adding-image-sequencely

The person was noticing a memory leak (that I've also experienced) in regards to removing a lot of images in a short amount of time (which is what cleanGroup()) does..

A strange thing they noticed is that strangely, the leak would not occur *sometimes* if the image was scaled down (weird, I know).

So I thought, since scaling an image right before removing it doesn't take a lot of overhead, if it even potentially reduces the occurrence of memory leaks, why not include it in with the function? The worst that could happen is absolutely nothing, the best that could happen is that a potential leak could get squashed (due to an unknown bug at this time).

Great question though! I was wondering how many people would ask me that (I've gotten a few already, lol).
uid: 7849 topic_id: 7489 reply_id: 27291


[TOPIC: post.html]
#35

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

It has been mentioned a few times that removing a group doesn't remove the Display Objects within the group. This was an issue six months ago but the object:removeSelf() was fixed to clear texture memory used by display objects.

I created the following test code to demonstrate that removing a group does remove the texture memory used by the display objects within a group.

print( "Texture Memory: " .. system.getInfo( "textureMemoryUsed" ) )

local image

local group = display.newGroup()
image = display.newImage( "Icon.png", 50, 0, true ) -- image 1
group:insert( image )

image = display.newImage( "Icon1.png", 50, 100, true )	-- image 2
group:insert( image )

image = display.newImage( "Icon2.png", 50, 200, true )	-- image 3
group:insert( image )

image = nil

-- The group now contains three images

-- Use a timer to display the texture memory and finally remove the group
local function onTimer( event )
	print( event.count .. ") Texture Memory: " .. system.getInfo( "textureMemoryUsed" ) )
	
	if event.count == 1 then
		print( "Removing group" )
		group:removeSelf()
	end
end

timer.performWithDelay( 500, onTimer, 2 )
You can put the above code into a main.lua file and duplicate and rename the Icon.png files to see the results.

What the code shows is the texture memory consumed for the three images and the memory going to 0 after the group was removed. This was run on build #311.

Removing a group or removing a Display Object removes all the texture memory used by the Display Objects and converts the objects into normal Lua tables. Any non-display properties added to the objects will still exist, including listener functions. If there are no other references to the objects, Lua's garbage collection should clean up the objects when it cleans other Lua variables.

The main purpose of group:remove and object:removeSelf methods is to remove the texture memory associated with display objects. Best practices say you should removed all object listeners and nil out the object if you still have access to the objects.

I'm also curious about scaling the display object before removing. Is there any test code that shows this is a real fix for memory leaks? Also, any test code showing memory problems would be helpful.

Update: It turns out the "scaling" mentioned as a cure for small memory leaks when removing a group/object was related to a touch bug that has been fixed in the current daily build (#311). See more here: http://developer.anscamobile.com/forum/2010/12/08/memory-leak-when-removing-and-adding-image-sequencely#comment-27408

Thanks,
Tom
uid: 7559 topic_id: 7489 reply_id: 27365


[TOPIC: post.html]
#36

p120ph37

[GLOBAL: userInfoPane.html]
p120ph37
  • Enthusiast

  • 46 posts
  • Corona SDK

@Tom

Although texture memory is freed, there is still something on the Lua side that does not get freed automatically when a group is removed. I took your example code and modified to to hilight this:

local group -- Use a timer to create and remove a group and wait for GC to occur--   and display memory stats at each iteration.local function onTimer( event )  if event.count % 3 == 1 then    print( "Creating group" )    local image    group = display.newGroup()    image = display.newImage( "Icon.png", 50, 0, true ) -- image 1    group:insert( image )    image = display.newImage( "Icon1.png", 50, 100, true )  -- image 2    group:insert( image )    image = display.newImage( "Icon2.png", 50, 200, true )  -- image 3    group:insert( image )	     image = nil    -- The group now contains three images  elseif event.count % 3 == 2 then    print( "Removing group" )    group:removeSelf()    group = nil  else    print( "It is now 500ms after the group was removed" )  end  collectgarbage() -- collect any outstanding garbage that we can  print( event.count .. ") Texture Memory: " .. system.getInfo( "textureMemoryUsed" ) .. " Lua memory: " .. collectgarbage( "count" ) )  end timer.performWithDelay( 500, onTimer, 21 )


Note that the Lua garbage collector reports a steadily increasing memory usage.
uid: 32962 topic_id: 7489 reply_id: 27746


[TOPIC: post.html]
#37

jonbeebe

[GLOBAL: userInfoPane.html]
jonbeebe
  • Contributor

  • 511 posts
  • Corona SDK

@p120ph37

When you did that, did you use your patched display.newGroup() function?
uid: 7849 topic_id: 7489 reply_id: 27747


[TOPIC: post.html]
#38

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

Well, your right about the memory leak. Your code shows after seven group create/remove cycles there is a 1.8 KB memory leak. I extended the loop time beyond 21 but only did garbage collection/display and the memory leak never increased but it never recovered either.

I modified the code to only create the group once and remove the three images instead of removing the group and I saw no memory leak. That means removing the objects is not the issue.

I than added this code before removing the group:
	-- Remove three images
		group:remove(1)
		group:remove(1)
		group:remove(1)
That fixed the major portion of the memory leak problem. At the end I only saw a 1 or 2 byte memory leak.

The bottom line is removing the group does remove the children's texture memory but it looks like there are still references remaining to the object variables which is not being cleaned up by Lua's garbage collection.

The cleanGroups code that has been posted does remove all the children in the group which is the proper way to handle this issue.

I will update our bug database but I expect it will be considered a low priority because of the workaround. I will update our documentation with the new recommendation.
Thanks for posting this code so we could resolve the issue.
uid: 7559 topic_id: 7489 reply_id: 27755


[TOPIC: post.html]
#39

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

I would just like to add that Ansca should not rely on workarounds for known bugs, as the developers are not always get informed about these workarounds!

I am sure that the majority of the developers have absolutely no idea about this thread, the potential leaks and the workaround you are discussing. Personally, I came to this thread accidentaly.

A more formal mean of "temporary workarounds for known bugs" should be published and the developers should be formally aware of it, to keep themselves updated on critical issues. Maybe the newsletter should mention critical issues to be addressed, beyond the marketing material.

Regards
uid: 7356 topic_id: 7489 reply_id: 27763


[TOPIC: post.html]
#40

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

@Magenda that's a very good point that I will raise internally.

I have brought up the issue of "work-arounds" in the past and a way to publish them through a FAQ or other page.

There at a number of reported bugs and it hard to tackle them all at once so priority goes to show-stopper bugs and bugs with no work-around. We need to a better job of making these work-arounds better known.

At the very least, this information will be added to the "Remarks" section of the API page for the method/property involved.

Thanks,
Tom
uid: 7559 topic_id: 7489 reply_id: 27782


[TOPIC: post.html]
#41

FrankS

[GLOBAL: userInfoPane.html]
FrankS
  • Contributor

  • 219 posts
  • Corona SDK

Sorry Tom, but I'm not sure if you understand what happened in this thread:

* none of us were aware that Ansca had "fixed" this recursive removeSelf bug

* we all see memory leaks, and we have no way to judge which ones impede performance on the device

* your public bug database has not been updated for 5 weeks and is known to be completely out of date with what you're using internally

* we have no access to the bug database that you're using internally... even though Carlos has promised this in the past

* the bug submission process is completely broken and the resolution is not transparent

* documentation is abysmally out of date - no indication what so ever what this removeSelf really does

* we all have spent/wasted loads of time trying to find work-arounds for bugs that supposedly have been fixed - this is not the first one

* we do not mind (help you) fixing new bugs, but I personally hate fixing known ones...

Please, please... Ansca allow us to help you by improving your communication about bugs and available resolutions.

... and maybe stop coding new features until you fixed that issue...

-FrankS.
uid: 8093 topic_id: 7489 reply_id: 27785


[TOPIC: post.html]
#42

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

@FrankS,

I never said this Group bug was fixed. I verified the problem and said the work-around is removing the group's children before removing the group.

About submitting a bug, you can do that with the "Report a Bug" link at the top of this page (when you are logged in).

The bug data base we use internally has been made available at: http://bugs.anscamobile.com
You need to create an account to view the information. We also post the bug fixes (and the database number) on the Daily Builds page (if you are a Corona subscriber).

As far as documentation, we are trying to update/correct the information. The most up-to-date information is on the API reference pages. You can add comments there if you feel something is missing or incorrect.

Based on this "group" bug, I updated a few of the API pages indicating the work-around to avoid the Lua memory leak.
uid: 7559 topic_id: 7489 reply_id: 27789


[TOPIC: post.html]
#43

Andriy Pertsov

[GLOBAL: userInfoPane.html]
Andriy Pertsov
  • Contributor

  • 211 posts
  • Corona SDK

"... and maybe stop coding new features until you fixed that issue..."
Absolutely YES, Corona full of features that allow to make good application, but also there are nasty bugs, that prevent from shipping, for example, our game (which crashed on Device and we could not handle this for about a month).

FrankS, thanks for point out all these problems!
uid: 9058 topic_id: 7489 reply_id: 27792


[TOPIC: post.html]
#44

FrankS

[GLOBAL: userInfoPane.html]
FrankS
  • Contributor

  • 219 posts
  • Corona SDK

Thanks very much for the http://bugs.anscamobile.com information.

I've been a paid subscribed since September, and follow the forums and doc pages almost every day, and I wasn't aware of this... maybe an updated doc page and more obvious links to this could probably help many more naive subscribers like me ;-)

Unless there are already obvious links to this and then I sincerely apologize...

-FrankS.
uid: 8093 topic_id: 7489 reply_id: 27795


[TOPIC: post.html]
#45

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

I have some good news. The group removal memory leak bug has been fixed and is available starting with daily build #318. Previously, removing a group with children (other display objects) would free the texture memory used by the children but still left references to the Lua variables. This caused the memory leak observed when repeatably creating and removing groups without first removing the children from the group.

It should now be safe to remove a group without having to remove the children within the group first.

Also, based on the underlining "removeSelf" code, any object listeners associated with the objects in the group, should be removed by the Lua garbage collection since the objects themselves are removed. This means there should be no need to object:removeEventListener for objects in the group. Any global event listeners (Runtime:AddEventListener) will still need to be removed manually.

Please test this yourselves and let us know if you see any problems.

Thanks everyone for your help and input.
-Tom
uid: 7559 topic_id: 7489 reply_id: 29108


[TOPIC: post.html]
#46

jonbeebe

[GLOBAL: userInfoPane.html]
jonbeebe
  • Contributor

  • 511 posts
  • Corona SDK

That's awesome, thanks Tom. Will let you know if I encounter any issues, but so far none (been using 318 all day).
uid: 7849 topic_id: 7489 reply_id: 29111


[TOPIC: post.html]
#47

FrankS

[GLOBAL: userInfoPane.html]
FrankS
  • Contributor

  • 219 posts
  • Corona SDK

Excellent Tom - no more need for monkey-patching the Corona-core...

-FrankS.
uid: 8093 topic_id: 7489 reply_id: 29114


[TOPIC: post.html]
#48

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

This should also fix the memory leak associated with Movieclips. The Movieclip library creates a group of images and then removes the group.

I'm glad this was fixed and avoids having to use the workarounds associated with removing groups and objects. The workarounds won't hurt but getting this fixed will make it easier to document how to use the APIs and makes it easier to use.

Thanks,
Tom
uid: 7559 topic_id: 7489 reply_id: 29115


[TOPIC: post.html]
#49

coderebelbase

[GLOBAL: userInfoPane.html]
coderebelbase
  • Contributor

  • 399 posts
  • Corona SDK

What? removing a group doesn't remove all of it's child objects?????

That's ludicrous
uid: 4596 topic_id: 7489 reply_id: 29197


[TOPIC: post.html]
#50

FrankS

[GLOBAL: userInfoPane.html]
FrankS
  • Contributor

  • 219 posts
  • Corona SDK

@Tom:

>> Any global event listeners (Runtime:AddEventListener) will still need to be removed manually

I can understand that if you register only a handler-function with Runtime, you cannot remove anything, but if you register a table-listener, then the Corona-runtime should be able to detect that the associated object has been self-Removed already and not invoke the handler and remove it from its handler list.

Is that implemented already ?
@singh206:

Not sure what you are referring to, but as I understand it, Tom just made that work...
The only thing he cannot do, is clean-up the orphaned objects which potentially have been decorated with additional properties and is held onto by explicit references in the code. Those orphans, however, will be garbage collected the normal way when no more references exist.
uid: 8093 topic_id: 7489 reply_id: 29212



[topic_controls]
Page 2 of 3 1 2 3
 
[/topic_controls]