autoric
Content Type
Profiles
Forums
Store
Blog
Product
Showcase
FAQ
Downloads
Posts posted by autoric
-
-
I'm actually not sure how to effectively create a codepen here. Running the profiler on the basic codepen does not show me a timeline instance.
-
I will try to reproduce with a codepen. There is interaction between angular and greensock that could be complicating the issue.
In short I am creating a timeline when I link a directive, and .kill()'ing that timeline when the directive scope is destroyed (and I can confirm that this is happening). However I end up seeing references to the .kill'ed timeline via the next chain, which I understand to mean that it is still referenced on the global root timeline.
Even waiting a minute or more, I continue to see the timelines referenced via the _next chain.
-
Hi Greensock!
I'm experiencing a memory leak in my application of DOM nodes and timelines. When I inspect the detached dom the shortest retaining path appears to be via a series of _next properties on other tweens and timelines.
Ultimately, I have a reference to some timeline or tween that I am maintaining correctly - it should still be available and in memory. And then, via a chain of _next / _prev properties, I seem to have references to timelines or tweens that I am done with but are still hanging around. And these are maintaining references to their target dom nodes.
It's possible I am misreading the profiler, or there is something going on. But I would appreciate any advice on what I should look at or do differently to manage my tweens correctly.
Thanks!
-
Jack, resurrecting this thread with another edge case.
I have put together a contrived example here:
See the Pen KFngp?editors=001 by anon (@anon) on CodePen
To recreate the issue begin dragging the tile around, and keep moving your mouse. In particular move the mouse outside of the grid or move it back and forth crazily. Eventually, you should see the tile snap to a new position and detach from the mouse.
I have traced the issue back to this line of code: https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/utils/Draggable.js#L1372
As the zoom tween fires, it is forcing the draggable instance to update. Occasionally the x or y properties change very slightly during syncXY (always on the order of e-15, possibly a js floating point error?), which causes the draggable instance to recordStartPositions again, when I don't believe it should be.
-
Looks great. This officially meets all of our requirements and lets us have a really, really awesome drag and drop. Thank you, Jack!
-
3
-
-
Code pen looks great, I'll try out the updated version.
-
No worries, I know it is. We really appreciate your support!
-
I've updated the codepen to set the transform origin as part of setup:
See the Pen rpJHh?editors=111 by anon (@anon) on CodePen
So, this explains the initial pop that I was seeing on first drag. However, it does not seem to address the main issue that I see. To reproduce:
- While scrolled to the top of the page, drag one of the boxes towards the bottom half of the grid, then release. Everything works well.
- Now scroll down the page so that box is in view again. Press and hold without dragging. T
- Now start to drag. As soon as the first drag event fires, the box will jump down the page.
-
1
-
-
Interesting - I'll follow up on this and see how it looks. Thank you very much!
-
@GreenSock - I've been working to integrate the new draggable preview with our project, and I've run into one major issue, which I have coded up here:
See the Pen rpJHh?editors=011 by anon (@anon) on CodePen
Basically, our DOM is a bit more complicated than the original example, and it turns out that matters. All of the math could use some tweaking, and thats fine, but the main thing to look at is what happens if you scroll down in your content and then press on one of the box elements.
- The onupdate fires, and fakes dragging with our bogus event while scaling is happening
- When I start actually dragging, the box element jumps down
-
@rhernando - thank you very much for the suggestion. I was pursuing this approach and it feels like it could get me there eventually, although with an unfortunate amount of math & state tracking.
@GreenSock - that looks fantastic. This is exactly the behavior I am expecting in the codepen demo. I will try applying this preview to our production code so that I can raise any other issues that I might see. Thank you very much for the quick response..
-
2
-
-
Example :
See the Pen dnuCJ?editors=001 by anon (@anon) on CodePen
Premise :
We have a draggable grid that may be larger than the user's current viewport. When they start to drag, we are scaling the draggable area to fit in their viewport, and scaling back out when they are done.
The Problem :
Greensock draggable watches deltas in the pointer X / Y position to determine dragging. This means that...
1) On the initial scale the pointer becomes detached from the draggable element.
2) Pointer x/y deltas do not account for the scaled content, so it ends up feeling like there is a drag resistance when there is not. The more the content is scaled, the more exaggerated this becomes.
Desired Outcome :
1) As the content scales, the x,y position of the draggable element is changed so that it remains underneath the pointer.
2) Pointer deltas are divided by scale so that there is no feeling of drag resistance.
I've been exploring this but cannot come up with a good comprehensive solution, especially for the first problem. For the second point, I am actually able to set a negative dragResistance
dragResistance = 1 - 1/scale
but it feels awkward when the pointer is detached from the draggable element. Any sugestions are welcome!
Thanks,
Erin
Memory leak issue and tween _next
in GSAP
Posted
So, it looks like timelines, including the root timeline, maintain a linked list of their child tweens and timelines.
Referencing the code here: https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/TweenLite.js#L758
When a tween is removed via completion or .kill, it takes its _next and _prev references and points them at one another. It does not then null its own _next and _prev references. This is technically valid, since it should be dereferenced and eligible for gc. However, if I write some bad code that keeps that tween alive in closure, I now have a reference path to its old next and prev tweens - which are probably also dead, and whose next / prev tweens point to other dead tweens. Etc, etc, etc.
Conclusion: The memory leak is caused by my bad code, but is made worse because removed tweens do not null their _next and _prev pointers, creating a large network of references that get kept alive by my leak. Unless there is a specific reason to keep the _next & _prev pointers of removed tweens alive it probably makes sense to null them in order to mitigate the impact of leaks.