Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

447 profile views

jchristof's Achievements


Newbie (1/14)



  1. @Jack I can faithfully reproduce it and our app remains allocated indefinitely by it's reference from tweenlookup: TweenLite._internals.tweenlookup.t104.target.children[0].imageToBase64.context._this3.appContext. This time I'm animating properties on plain-old-objects, and dom elements. I haven't had time to pull together a simple repro but generally: Start animation on object properties Call TweenMax.killAll() setTimeout(()=>{ //wrap in settimeout or not - doesn't make a difference Shut down our app In-flight tweens update and complete - the bodies of onupdate() and oncomplete are wrapped in try/catch },500); No exceptions in the console log. Just now I removed the try/catches from the body of onupdate and oncomplete and am able to crash chrome on a heap profile if I allow exceptions to bubble up into the TweenMax dispatcher for those functions [dispatcher exception jpg] I guess for the moment is there at least a safe way for me to free that tweenlookup that won't interrupt other animations running in TweenMax? I can't leak an appContext.
  2. I'll explain that in a second. However, I've immediately discovered another issue. The following now appears in the heap profile after running animations. Again, I've ensured we've released all references to our application (appContext in the picture) but something called target is preventing our app from being gc'd: TweenLIte._internals.tweenLookup.t59.target.(my control).(my application)
  3. http://codepen.io/jchristof/pen/XppvwE <div id="dontholdme"></div> TweenMax.set('#dontholdme', { x: 0, y: 0, width: 100, height: 100, background: '#ff0000', position: 'absolute' }); setTimeout(()=>{document.getElementById("dontholdme").remove()}, 1000); Then sometime in the future open chrome devtools->profiles->take heap snapshot. See that the window is holding a ref to CSSPlugin which is holding a ref to the disconnected dom element keeping it alive in memory.
  4. One other note - in order to function correctly we need to remove parts of the dom tree anytime a user elects to change part of the view - whether or not animations are alive or influencing any of those elements.
  5. @OSUblake It's our own framework that runs as an application in the page. The important part of the spa-ness in this instance is that the application page is required to run indefinitely and should never need a frame refresh to manage memory.
  6. So going back to this example, if I run a heap profile 30 min. later, the window.CSSPlugin still has a handle to that element. What can I do manually to safely clear or reset it so that the CSSPlugin will release that element? I don't want to do anything that would compromise other running animations.
  7. Our uses of TweenMax all ignore the return object and use the static form. We don't new Tween() anythere. In the case above there are several set() calls on the element: TweenMax.set(htmlElement as any, { x: viewModel.left, y: viewModel.top, width: viewModel.width, height: viewModel.height, background: viewModel.background, position: 'absolute' }); TweenMax.set(this.domElement as any, {x: value}); TweenMax.set(this.domElement as any, { y: value }); TweenMax.set(this.domElement as any, { width: value }); TweenMax.set(this.domElement as any, { height: value }); None take the return value. I have tried TweenMax.killAll() to try removing the window.CSSPlugin cached element.
  8. Sorry, let me rephrase that and go back to my original post and an example: I create a div attached to the dom. I use TweenMax.set() to position the div. I call remove() on the div - it is no longer rendered by the page. The div remains allocated and appears in heap profile. The div is rooted to window.CSSPlugn. I was not expecting gsap to keep a reference to this element. I expected the element to be reclaimed by the garbage collector after removing it. Is there a way to ensure that TweenMax does not cache elements after they are removed from the dom? For us, a node in that state produces unexpected side-effects that will be tricky to work around.
  9. No, in our case elements that are not garbage collected (like this one in the CSSPlugin) after they are removed from the dom prevent the garbage collector from running on our removed controls and unused app instances (references from the element to those items.) Ultimately what I'd like is for TweenMax, CSSPlugin etc. to not hold an element past it's being removed from the dom. I don't mind calling a function to do this. TweenMax.releaseDetachedDomNodes(); Multiples of our same app can run at the same time, so tearing down the whole TweenMax is not an option since one app may be running animations at the same time another is being unloaded. Somehow grouping tween functionality might also work for us if I could say: TweenMax.releaseEverthing(relatedToApp1); and then later TweenMax.releaseEverthing(relatedToApp2);
  10. We've got a single page app here using TweenMax. Taking a look at the heap profile I see in my simple example that CSSPlugin is holding a reference to an html element that was removed from the dom. Could someone point me to documentation on how to release any held elements w/o breaking any follow up usages of the same TweenMax instance?