Jump to content
Search Community

Memory Leak with ThrowPropsPlugin

David An test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I am already member of Greensock Club to purchase ThrowPorpsPlugin.js but it has memory leak issue.


I have included TweenMax.js, Draggable.js, ThrowPropsPlugin.js and used this code:

Draggable.create(".kr-thumb-inner", {
					type: 'x',
					edgeResistance: 0.65,
					bounds: '.kr-thumb-wrapper',
					cursor: 'pointer',
					dragClickables: true,
					throwProps: true

Any transition didn't start so no moving element, but memory is continuously increasing.

When I get rid of ThrowPropsPlugin.js, memory leak issue was gone, but It was always happen until I remove ThrowPorpsPlugin.js even I removed this option: "throwProps: true".


Please check Greensock sample page itself. : https://greensock.com/throwpropsplugin


It has also memory continuously increasing. You can see the page has that issue if you SHIFT + ESC in Chrome.


I really need this plugin but not useful if it has such issue.


Please HELP ME!

Link to comment
Share on other sites

We certainly don't want any memory leaks - could you explain why you think there is one? I just profiled that page and it looked normal to me: 

http://prntscr.com/55v1q8(I drew arrows pointing to where memory dropped and was reallocated, likely from a garbage collection event). Usually a memory leak means that it constantly goes up and never goes back down. 


Keep in mind that it is very normal to see memory increase for a while, and then the browser will run garbage collection and sweep away memory that had been allocated to local variables in functions, etc. ThrowPropsPlugin has a VelocityTracker in it, and if you track a property's velocity, it must run a function and check that property about 33 times per second to get the necessary data to calculate the velocity accurately. It's not very CPU-intensive, but anytime you run a function and create local variables inside that function, it uses memory, and then the browser marks that memory as eligible for gc and it gets swept away on the next cycle (which happens whenever the browser decides). 


So if you still think there's a memory leak, would you mind maybe taking a screencast recording of what you're looking at exactly? As far as I can tell, there aren't any memory leaks but I could certainly be wrong. 

  • Like 1
Link to comment
Share on other sites

Hi David An  :)


i think that increase's is natural , but your screenshot's so weird !....  :geek:
pls check your browser extensions and .... 
In fairness, i opened 2 tab in chrome incognito mode about 20min without any actions :
1- the GSAP example page that you mentioned (  with so many elements to render , GSAP engine calculates , ThrowPropsPlugin ,  active Slider at the bottom of the page and .... )
2- Google home page ( basic graphic , only a few elements to render , without any active javascript engine and without any Request Animation Frame and .... )
and you can see the result screenshot in attached file , as you can see after 20min google page used 34,028K and GSAP page used 67,376K ...... there isn't any Photoshop magic  ;) 
and another thing , in your screenshot i saw that you'r using Adblock Plus extension , pls check this out :


Link to comment
Share on other sites

Hello Diaco


Thanks for your reply. But I think javascript is stopped in inactive tab in chrome so in your screenshot, you couldn't see memory increased.

If you keep that page activated, you will see the issue.


And It's not based on Adblock extension. I removed it on my Chrome but same issue!

Link to comment
Share on other sites

If I look at the task manager of Chrome I also have that behaviour on this page. Switching to an tab with the ThrowProps example results in that page increasing again, switching back and that Chrome task stops and this page adds KB's again.


Maybe not that usefull but I wonder if it has to do something with especially the throwprops plugin.

Link to comment
Share on other sites

Hello OzBoz..


I don't believe this to be a bug or memory leak with GSAP!


If you like you can listen to events, when the browser window or browser tab loses or gain focus..  and then pause()  and resume()  your animation accordingly.


Check out this Forum Topic - Cross browser to detect browser tab or browser window is active:




Example of use:

See the Pen sxgJl by jonathan (@jonathan) on CodePen


Also i made it into a jQuery plugin so you can add it to your projects with ease: TabWindowVisibilityManager.zip


This way you can pause  and resume  your tweens.. and manage the visibility state of browser tabs or browser windows.



  • Like 1
Link to comment
Share on other sites

We don't have any tween to manage the visibility state of browser tabs or windows.

Please check this: https://greensock.com/throwpropsplugin. In that page we didn't animate any element but memory is increasing. I have exact same issue on my site. 

Not sure what ThrowPropsPlugin is doing with memory on that page which has no element animating.


And it should not be increased even if we have any number of tweens. Memory should be released and dropped to normal. If it use always 1GB of memory without increasing, it's not memory leak issue but it's continuously increasing.

Finally the tab crashes!

Link to comment
Share on other sites

Can anyone else reproduce this? I've tried in Windows and on my Mac - I cannot reproduce it at all, not even once. Memory fluctuates between two pretty normal/healthy amounts. I wonder if there's something different about David An's system, but why would it only affect things when ThrowPropsPlugin is loaded? I really wish I could figure out a way to make the problem happen - I just can't. Carl tried too. We left tabs open for hours. No crashes, no crazy memory. Nothing. 


[scratches head]

  • Like 1
Link to comment
Share on other sites

Hey guys, I tried also.. tested on latest Chrome .. Windows 7 .. I left tabs open all day \ night. I even fell asleep, and came back and no crashes or high memory use.


David An, when your testing this.. are you testing this in a Incognito (Private) Tab or Window?


Incognito Mode disables all extensions, and plugins in the browser so you can better test your code. Browser extensions and apps can skew results when testing performance and memory. Plus in Chrome .. it will run a separate process for each tab and window you have open.


I couldn't reproduce this at all.



  • Like 2
Link to comment
Share on other sites

I think my post wasn't very clear so I made a little movie to explain this forum page does the same. And no, I didn't wait for hours but it's odd it adds 150kB every second to the memory use. At least, I think so :)



As you see the memory use keeps rising without doing anything. If you open another tab and switches from the Greensock tab the memory keeps steady. Switching back will raise the memory use again.
Like I said before, it's maybe a Greensock thing but not especially a Throw Props thing.
Link to comment
Share on other sites

my friend it's not about GSAP , maybe for some reason that happened in greensock.com webpages

check GSAP library in your codepens or local file , every things works fine .


Well it's not that I bother that much but I think it's what the topic starter meant. Just went some minutes away and mem-use of this page is over 400MB now. If i look at 

See the Pen duBFp by OzBoz (@OzBoz) on CodePen

the behaviour is normal and mem use stays about 40MB. It's still weird I think. Since the TS used a greensock.com page I just tried to explain it a bit.


Curious what causes a forum page to consume 420MB (now) memory. Or for example that draggable page.

  • Like 1
Link to comment
Share on other sites

Hello Guys.


I have researched GSAP for three days and finally found something.


Most of apps using GSAP have the same issue - memory leak.

For instance, some slider using GSAP - Revolution Slider and Layer Slider have this memory issue.


Please check their demo sliders: (They don't use Draggable or ThrowPropsPlugin but have the memory issue.)

Revolution Slider: http://themes.themepunch.com/?theme=revolution_jq

Layer Slider: http://kreaturamedia.com/layerslider-responsive-jquery-slider-plugin/


If I keep their demo pages tab activated on Chrome for 4 ~ 5 hours, memory usage of the page reaches to over 1GB.


But Others not using GSAP have no such issue.

For instance, Master Slider(Even they have similar animations):



It's not any browser extension problem or any other reason, I have tested in Incognito mode of Chrome on Windows 7 64 bit System (4GB of RAM)

Sliders using GSAP I have researched and even greensock.com pages have same issue so I am surely saying GSAP has something to fix on such problem.


I am developing a slider as well and have such issue.


I really hope GSAP dev team will review through their all libraries and fix such issue as I really need their libraries. That's why I purchase their membership.

Link to comment
Share on other sites

We definitely want to fix any kind of memory leak, without a doubt. I'm just not sure there is one. Here's a summary of the information I have thus far:

  1. Neither Carl nor I can reproduce the problem on any computer, Windows or Mac. I have left GSAP-driven pages open for many days at a time...no crashes or problems. 
  2. I tested various GSAP-driven pages in Chrome's Dev Tools and they show normal garbage collection routines. 
  3. In the past, we have had some memory and garbage collection experts profile our code and confirm that it was in good shape. That doesn't mean a memory leak didn't sneak in since then - I'm just saying that there didn't appear to be one when they tested.
  4. Vast numbers of major corporations use GSAP including Google, McDonald's, Intel, Samsung, etc. and none of them have reported any such problems. I'd expect that if there was a major memory leak, someone would have reported it by now. 
  5. You say that any page using GSAP has the problem, but we have other users saying that's not the case and they've tried it on codepen and locally and those showed no such leaks. One other user said they think there might be a problem with non-GSAP code on greensock.com, but that has yet to be confirmed. 

See why I'm baffled? I definitely want to identify and fix any problems that exist. I have a few questions for you that may help me make more progress:

  1. What version of GSAP are you using? 
  2. Have you tried earlier versions of GSAP? For example, http://cdnjs.cloudflare.com/ajax/libs/gsap/1.12.1/TweenMax.min.js or http://cdnjs.cloudflare.com/ajax/libs/gsap/1.11.8/TweenMax.min.js  or  http://cdnjs.cloudflare.com/ajax/libs/gsap/1.10.3/TweenMax.min.js
  3. Does the problem go away if you call TweenLite.ticker.useRAF(false)?
  4. Which browsers have the problem? Which have you tried? (please provide version number and platform, like windows or mac)
  5. Do the number of animations impact how quickly the memory builds up or is it relatively constant regardless of how many animations are happening? 
  • Like 1
Link to comment
Share on other sites

Hello again,


In my tests on (actual PC) Windows 7 (64-bit) using latest Firefox (33.1.1) and latest Chrome (38.0.2125.122 m)

I even went to Samsung .. McDonalds and the GreenSock.com ... and i could not replicate this.


I even left the browser on all day yesterday and still no such memory leaks!


I did find numorous webkit bugs about memory leaking .. but those are webkit browser bugs.. not GSAP!

Bug Reports webkit:

Plus how are you profiling the memory leak?


.. here is an article on using Chrome dev tools to take snapshots for memory leak debugging:

Best way to debug memory leaks in the browser, specifically in Chrome, is to take snapshots. The OS's task manager will only the processes, but wont give you specifics when debugging memory leaks in Chrome.


I could not see this at all

  • Like 3
Link to comment
Share on other sites

I do think it's a bug in Chrome. My version was 38.0.2125.111 m and since it updated after a 'about Chrome' to 38.0.2125.122 m I'm using the latest version now. Still the same though. Firefox on the other hand doesn't have this issue 32.0.3 and after update 33.1.1. It does use a lot of memory but it goes a bit up and down.


The Revolution Slider page is hard to see, it loads so much data while being there so it's pretty normal. On the other hand, I couldn't see a Intel, Samsung, Google or McDonalds page to look at.


To make the problem even more weird, now my mem use at this page is steady. But closing some tabs and it's only gaining again. I really think it's a Chrome thing. And like I said, I'm only watching because I'm curious. Plenty of memory and my site which uses throwprops etc doesn't have the issue. 


@David An if you want I can send you a private message with the site I'm working on so you can see how it behaves.

Link to comment
Share on other sites

  • 2 weeks later...

Guys, I used Memory Tracker for AS3 :




And I confirmed that the target that I sent in for tween wasn't been null (as going through TweenLite codes and also ThrowProps codes) causing memory reference to the target itself retained.


As when I commented the .to method and the reference for that target is no longer there (comment off the tweening). 


Please do get back to me ASAP on this, the leak is blocking our project forwarding.


Thanks and Regards,


Link to comment
Share on other sites

Shakespeare87, what makes you think there's a memory leak? Can you provide some evidence? What can we look at specifically - do you have a reduced test case maybe? 


Please keep in mind a few things:

  1. GSAP purposely retains a reference to the target for up to about 2 seconds after its last tween completes. This is an optimization that allows us to very quickly perform overwriting routines & logic. Again, there's a sweep every roughly 120 frames/ticks where GSAP releases things that need to be released. So if you are performing some kind of test immediately after your tween is done, it would be perfectly normal for there still to be a reference remaining. Please give it a few seconds to release things in your test. 
  2. Did you realize you posted in the JavaScript forum? It sounds like you're working on a Flash project (right?)

We'd be happy to take a look at a reduced test case that you can provide that shows the problem. (Please don't just send us your whole set of production files with hundreds or thousands of lines of code - just create a separate FLA that reproduces the problem with the least amount of code and assets possible). We definitely want to fix any memory leaks that exist. 

Link to comment
Share on other sites

  • 3 months later...

I encountered a memory leak too, but from TweenLite itself.


It's pretty simple to reproduce : Include TweenLite.js, record the timeline using Chrome and watch the memory heap grow.


The scary part is that it leaks even when doing nothing. Just including Tweenlite is enough.


I could nail the origin to the _checkTimeout function :

		//some browsers (like iOS) occasionally drop the requestAnimationFrame event when the user switches to a different tab and then comes back again, so we use a 2-second setTimeout() to sense if/when that condition occurs and then wake() the ticker.
		var _checkTimeout = function() {
				if (_tickerActive && _getTime() - _lastUpdate > 2000) {
				setTimeout(_checkTimeout, 2000);
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...