Currently, I'm looking at 'LPP-4879 - Memory leak in
"LzUtils.callback"', and I'm a bit concerned about how "destroy" (for
LzNode, LzView, LzSprite) should work, how it actually worked in OL3.3.x
days and what happens right now in OL4.x.
Short summary for OL3.3.x:
LzNode#destroy(..):
- setting internal flag "__LZdeleted"
- send "ondestroy" event
- ... (next steps skipped)
- recursively invoking destroy on all subnodes
- removing "name", "id"
- removing delegates, events, handlers
- removing itself from immediateparent's subnodes array
- delete "data"
LzView#destroy(..):
- ... (first steps skipped)
- removing itself from immediateparent's subviews array
- clean up "updatePlayDel" and "doQueuedDel"
- invoke "super.destroy(..)"
- return, in case of recursion
- remove "carefully" MovieClip(s) with "__LZFinishDestroyOnIdle"
- hide view [setVisible(false)]
- ... and send "onremovesubview" event
---
Things get a bit more complicated for OL4.x:
LzNode#destroy(..):
- setting internal flag "__LZdeleted"
- send "ondestroy" event
- ... (next steps skipped)
- recursively invoking destroy on all subnodes
- removing "name", "id"
- removing delegates, events
- removing itself from immediateparent's subnodes array
- delete "data"
- ...
Differences:
- step "removing handlers" has been removed
LzView#destroy(..):
- ... (first steps skipped)
- invoke "sprite.predestroy()"
- removing itself from immediateparent's subviews array
- invoke "super.destroy(..)"
- return, in case of recursion
- invoke "sprite.destroy()"
- hide view [setVisibility('hidden')]
- ... and send "onremovesubview" event
Differences:
- added step: invoke "sprite.predestroy()"
- removed step: clean up "updatePlayDel" and "doQueuedDel"
- added step: invoke "sprite.destroy()"
- removed step: remove "carefully" MovieClip(s) with
"__LZFinishDestroyOnIdle"
Notes:
- invokes "sprite.destroy(..)" always with false as the argument(!)
--> this is a bug, must be true instead of false
LzSprite#destroy (dhtml):
- checking internal flag "destroyed"
- recursively invoking destroy on all __children, if argument
"recursive" is true (will never happen see above)
- destroy __ImgPool
- remove js-events and various html-elements
- ... and setting internal flag "destroyed"
LzSprite#destroy (swf):
- recursively invoking destroy on all sprites of the subviews of its
owner, if argument "recursive" is true (will never happen see above)
--> wait a min', on all subviews of its owner? so that'd be an
empty subviews array, reason: see [step 3] of LzView#destroy(..)
--> that's just another bug
- clean up "updatePlayDel" and "doQueuedDel"
- remove MovieClip(s) with "__LZFinishDestroyOnIdle"
---
If anybody could follow me up to here: I'm just curious to know, how to
solve these two bugs.
I'd say, we need to call "this.sprite.destroy(true)" in
LzView#destroy(..), that's somehow obvious.
But the LzSprite(swf)-subview issue is a bit more complicated:
To match OL3.3.x behaviour, we could simply move 'clean up
"updatePlayDel" and "doQueuedDel"' to "LzSprite#predestroy(..)" and
remove this "recursively destroy sprites of owner's subviews"-stuff
completely, so that LzSprite#destroy(..) will only call
"__LZFinishDestroyOnIdle".
BUT, do we need to remove properly ~all~ MovieClips to avoid
memory-leaks or whatsoever? However, we didn't do this in OL3.3.x...!?
And a last question:
Why don't we remove all handlers in LzNode#destroy(..) anymore?
- André
