Jump to content
GreenSock

Search the Community

Showing results for 'overwrite'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge

Categories

  • FAQ

Categories

  • Examples
  • Showcase

Categories

  • Products
  • Plugins

Categories

  • Learning Center
  • Blog

Categories

  • ScrollTrigger Demos

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Twitter


CodePen


Company Website


Location


Interests

  1. So I'm implementing a smooth scroll like this: useEffect(() => { const container = document.querySelector(".scroll-container"); document.body.style.height = container.scrollHeight + "px"; const onScroll = () => { gsap.timeline() .to(".scroll-container", { y: -pageYOffset, overwrite: "auto" }, 0) } document.addEventListener("scroll", onScroll) }, []) The smooth scroll is working fine, but its height is not being calculated properly. In other words, the scrollHeight I get from the container, won't be enough to scroll the whole container using smooth scroll. How do I calculate the height I need for smooth scroll?
  2. Another alternative is to use a completely different approach: Position the cursor element in the center of the pink element. Set its scale to 0. In the mouseenter of the pink section, animate the cursor element's scale to its normal scale. In the mousemove of the pink section, animate the position of the cursor to the mouse position. Make sure to overwrite any animations affecting the position of the cursor element. In the mouseleave of the pink section, animate the cursor element's scale back to 0 and its position back to 0, 0.
  3. Hey Coopski and welcome to the GreenSock forums. You're making one of the most common ScrollTrigger mistakes: nesting ScrollTrigger in tweens within a timeline. Doing so doesn't make much sense because the timeline and the ScrollTrigger try to control the animation. Once you fix that, you still have a logical error though: since your ScrollTrigger start point is before the initial scroll position, both your start animation and your ScrollTrigger are trying to set the value at the same time so one will overwrite the other. You probably want to wait to create the ScrollTrigger until after the load animation has finished. To prevent the jump in state caused by the initial scroll position affecting the ScrollTrigger, you could use a numerical scrub. Something like this: https://codepen.io/GreenSock/pen/mdEKYgE?editors=0010
  4. Hey @imChris, It could be a questions of positioning (more here) e.g. try timeline.to(boxInner, { x: sectionMovement.getAttribute('data-x'), ease: animationEase, //overwrite: 'auto' },0) Happy precise timing ... Mikel
  5. Hey Zach, Superb! That's exactly the effect I was looking for -- and has also given me a couple of new pointers for the future too. It makes total sense - I wasn't aware you could a) attach a tween to the onEnter/onLeaveBack calls in that way and b) hadn't properly grasped the impact/usage of the "overwrite:true" prop to kill the tween either. I'll make sure I do some reading around that one Many thanks (again!). Cheers!
  6. Okay, thanks again for your help. Looking at this a bit more, I agree with you on the necessity of the overwrite because I'm not really seeing a way around that. I may end up going that direction.
  7. Unfortunately we don't have the capacity to make every edge case meet your needs. I would say the overwrite is pretty necessary to prevent the conflicts. Best of luck getting it working the way you need it to be working!
  8. Thanks for your reply and suggestions, Zach! Much appreciated. Those changes have brought me very close to a solution. On touch devices, I am still having a few issues, however. Basically, if the Draggable section is part way in the viewport, and the user tries to grab it and scroll back up, Draggable events are firing and the user can't really scroll up normally. I messed around with a few options using the deltas and Draggable.enable()/disable(), but can't quite get it - basically I would need a way to disable Draggable if the user is scrolling vertically. As a side note, I did have to remove the overwrite: 'auto' on the updateProxy function or else that will kill the inertia movements. And related to that, when inertia movements are still going and a touch user tries to grab the screen to stop, a bunch of flickering starts happening as the native scroll position and the inertia movements are fighting. I suppose this is where the overwrite would come in handy, but I would really like to have the inertia preserved if possible - do you happen to have any additional ideas on that? Thank you again for your help!
  9. Hi Zach, Thanks for the reply. I stripped out everything and was finally able to pinpoint the issue to a gsap default setting of `overwrite: true`. The docs say: If true, all tweens of the same targets will be killed immediately regardless of what properties they affect. If "auto", when the tween renders for the first time it hunt down any conflicts in active animations (animating the same properties of the same targets) and kill only those parts of the other tweens. Non-conflicting parts remain intact. If false, no overwriting strategies will be employed. Default: false. Not really sure I understand how this applies to my case, but anyway, I'm glad I finally figured this out. Thank you for the suggestion.
  10. Hi! I tried to recreate the navigation https://www.steven-hanley.com/ So now I have in my codepen working example, The problem is when deltaX is 0, the animation starts to kill itself in a tick because of overwrite: true. My question is - is it possible somehow kill animation with smooth decay? I mean when my deltaX is 0, the tween should animate position of x to 0 with duration, not immediately. Thanks in advance!
  11. You're now making a variation of one of the most common GSAP mistakes Just use gsap instead of this.tl. You might want to set the global defaults for GSAP if you're doing that: gsap.defaults({ overwrite: 'auto' }).
  12. Thanks! I rewrote the code using functions - looks much better)) But still have a small problem. Clicking two fast pushes animations in a line even with overwrite. So all of the triggered animations will play till the end. Is there anyway to stop it? Kind of stopping everything and playing only the last tween? https://codepen.io/kutalev/pen/dyXPOMb
  13. I have a circle which is supposed to be transformed in the direction of the cursor all time. node.addEventListener("mousemove", e => { const {x, y, width, height} = blob.current.getBoundingClientRect(); gsap.timeline() .to(blob.current, { duration: 10, x: e.clientX - (x + width / 2), y: e.clientY - (y + height / 2), force3D: true, overwrite: "auto", ease: Linear.easeNone }, 0) }) This is fine, but includes unwanted behavior: when being further away from the circle and rapidly changing direction and distance from the circle, there obviously will be a change in speed since the distance for the circle to travel in this 10 seconds gets shorter/longer. How can I ensure the same travel speed all the time, no matter where the cursor is?
  14. Hey Tee. First off, I recommend that you modify your mousemove function. The one that you have could be improved like so: node.addEventListener("mousemove", e => { const x = e.clientX / 10; const y = e.clientY / 10; gsap.to(blurRef.current, { yPercent: -30, x, y, duration: 1, overwrite: "auto" // very important }) }) However you could go even further improving the performance using GSAP's .quickSetter() which is what I would do in your position. When combining animations that are animating the same properties of the same objects, it's usually best to animate a container of the element with one animation and the actual element with the other element. That way you don't have to worry about managing the combination of the animations, it just works because the animations are on different elements. So I would recommend adding a new container just around your blur element and animating that with one of your two animations. In terms of writing that CSS animation in GSAP, here you go: gsap.fromTo(blurRefContainer.current, { y: -10 }, { y: 15, repeat: -1, yoyo: true ease: "power1.inOut", duration: 1 });
  15. Hi, I am using Tweenmax and ScrollToPlugin for smooth scroll effect on my website. I have used following code for same. $(function() { var $window = $('#outerWrapper'); //Window object var scrollTime = 2.5; //Scroll time var scrollDistance = 400; //Distance. Use smaller value for shorter scroll and greater value for longer scroll $window.on("mousewheel wheel DOMMouseScroll touchmove tick", function(event) { event.preventDefault(); var delta = event.originalEvent.wheelDelta / 120 || -event.originalEvent.detail / 2; var scrollTop = $window.scrollTop(); var finalScroll = scrollTop - parseInt(delta * scrollDistance); TweenMax.to($window, scrollTime, { scrollTo: { y: finalScroll, autoKill: true }, ease: Power1.easeIn, //For more easing functions see https://api.greensock.com/js/com/greensock/easing/package-detail.html autoKill: true, overwrite: 5 }); }); }); and it really works great on mouse wheel scroll. I want same effect of smooth scroll when someone try to scroll website using trackpad on laptop. Is any solution for same? I tried with all events "$window.on("mousewheel wheel DOMMouseScroll touchmove tick", function(event) { " but this gives regular scroll while using trackpad, not smooth scroll effect.
  16. Hey dnknapp and welcome to the GreenSock forums. Thanks for supporting GreenSock by being a Club GreenSock member! You're making one of the most common ScrollTrigger mistakes: .to() tweens with ScrollTriggers get evaluated immediately so you need to set immediateRender: false if you don't want that to happen. In this case you should also set overwrite: 'auto' to make sure the old tween is killed when the ScrollTrigger is reached. But this helped us find a bug in the current version that made it glitch even if you did that. We fixed the bug and you can see the working version below (you may need to clear your cache): https://codepen.io/GreenSock/pen/5ee69c59eea050ee5b3efcf75313bf5e Visual-Q's method also works
  17. Hey dawid660. A few notes: In general it's best to create animations at the start and use control methods inside of your functions for interaction. I talk more extensively about that in my article about animating efficiently which I highly recommend. Part of what makes killing off the old animation more difficult is that you don't save the reference to any of the tweens that you're creating inside of the arrowsAnimation function. One way you could do so is to create a timeline within that function and add all of your tweens to that timeline. Then return the timeline from the function and save a reference to that timeline. That way you could use the variable (that points to the timeline) to kill off the animation. Alternatively if you are setting all of the properties that you're animating in the intersection observer callback you could use overwrite: 'auto' or overwrite: true to kill off any tweens that are in conflict. Using GSAP's ScrollTrigger would likely make this sort of thing more easy. You don't need the quotes around numerical values. That's one of the most common GSAP mistakes.
  18. The default of overwrite: false is the most CPU-friendly option...it assumes you're responsible with the way you create your animations (not creating conflicts). 2nd fastest is overwrite: true because that doesn't have to care about which properties - it just obliterates any active tweens of the same object. We don't plan on changing any of those overwrite options if that's what you're asking. It won't cause a conflict, no - the whole purpose is to avoid conflicts But I think it'd be rather strange to do physics animations with overwrite: "auto" but it's not wrong or anything. Frankly, you're not going to notice a performance difference unless you really push things hard and have hundreds/thousands of things initiating animations simultaneously. And remember, overwriting logic only runs ONCE for a tween (when it renders for the first time). It's not like it's constantly draining resources looking for things to overwrite. As you probably know, we put a lot of effort into making GSAP highly performant. I may be misunderstanding but no, I don't see any reason to use isTweening() in that scenario. Here's some very basic pseudo code: // this replaces your setTimeout() logic. Just use a delayedCall - remember, it's just a tween with an onComplete, so you can pause()/restart() it. let hideControlsDelay = gsap.delayedCall(1, hideControls).pause(); function onPointerEnter() { hideControlsDelay.pause(); // don't hide controls when the pointer is over them gsap.to(controls, {autoAlpha: 1, overwrite: true}); // animate controls in } function onPointerLeave() { hideControlsDelay.restart(true); } function hideControls() { gsap.to(controls, {autoAlpha: 0, overwrite: true}); // animate controls out } hitArea.addEventListener('mouseenter', onPointerEnter); hitArea.addEventListener('mouseleave', onPointerLeave); I guess I don't really understand why isTweening() would be helpful. Maybe I'm missing something. Anyway, does that help?
  19. Thanks for the info. Since it is my opensource project and I want it to be as forward compatible and versatile for people that might not be using it in the same ways that I am now, is overwrite:auto going to remain current or are things moving toward a more CPU friendly way of handling things? Also lets say that someone wanted to do a physics simulation behind the video player using GSAP would the overwrite:auto cause conflict? About what you said about the isTweening, I think the isTweening might be the only way to tell tweening object to stop and change direction handled by multiple but similar events, like when you mouse over the player you need to see the cursor and the controls. It's the same for the controls but you no longer need the timeout to hide the controls and the cursor; but you want a timeout when leaving the controls to hide the controls and the cursor (especially if the video is playing) all of which need to be interrupted and overwritten by the last event in 1/10000000 of a second depending on how fast your kid(or me) is spasming the mouse around. Im I right in my thinking if using isTweening in that scenario? If not Im thinking that im thinking about this entire redesign thing wrong then. Thanks again Jack!
  20. Yeah, it definitely looked like some refactoring was in order there There is an onInterrupt() callback that'd tell you when something gets killed prematurely (like with an overwrite:"auto" kicking in). And for the record, overwriting isn't "bad" or anything - you just need to be aware of what you're doing. I've seen people creating a bunch of conflicting tweens due to logic in their code and then they wonder why they're running into performance problems or odd "glitches" (which aren't glitches at all, since GSAP is doing exactly what they're telling it to do). Example: create a 1-second rollover fade-in tween and a 0.5-second rollout fade-out tween that affects the same object...now rollover and immediately rollout. Without any overwriting, you've now got two tweens fighting over the opacity of the element, and the fade-out tween "wins" because it was created last...but it finishes after 0.5 seconds at which point the opacity JUMPS to something like 0.8 and goes up to 1. Some people are like "GSAP is broken"...but no, it's not. The fade-up tween still had about 0.5 seconds left to go, so as soon as the fade-out tween stopped overruling it on each tick, you see the fade-in finish. See the issue? It always makes me a little nervous when I see if (gsap.isTweening(...)) because it's almost always in the context of a bad UX decision like making the UI unresponsive until certain animations finish (a pet peeve of mine). Or someone is trying to mask a logic issue in their own code by slapping an .isTweening() condition on it. I'm not saying you're doing that - sometimes there are legitimate reasons to use .isTweening(), absolutely. Just be careful Glad to hear the auto overwriting resolved things for you. Good luck with the port!
  21. Ugh, sorry to hear about the trouble, @N1DAN. Sounds super frustrating. I'm not in a position to be able to wrap my head around 2500+ lines of code and debug it for you, but the only thing that came to mind is that perhaps you're creating conflicting tweens. Before version 3, GSAP used overwrite: "auto" as the default which means that it automatically tried to find competing tweens of the same properties of the same objects and killed any it finds. For some people that was a bit confusing, plus it cost CPU cycles so in version 3 there is no overwriting by default. You opt-in to ensure developers are more aware. Of course it's best to not create conflicting tweens to begin with, but try just adding this to the top of your file: gsap.defaults({overwrite: "auto"}); Does that resolve anything for you? Other than that, there really isn't anything I can think of that'd cause such simple tweens to behave differently in the newer version. Trust me - the new version is far more capable, plus the syntax is easier and the overall file size is significantly smaller. So you're making a good move by updating. I'm confident that once you get past this issue, you'll love working with GSAP 3. Let me know how that overwriting tweak goes. I have a sneaking suspicion it'll solve things for you based on what you described.
  22. That's because you're trying to animate an attribute but you forgot to use the AttrPlugin, so GSAP is taking you literally and attempting to directly get/set properties like "stopColor". Minor note: you don't have to pass an Array of selector text - you can just use a normal selector text string with commas: // BAD gsap.to(['#cursor-gradient-1', '#cursor-gradient-2'], { stopColor: '#000' }); // GOOD gsap.to('#cursor-gradient-1, #cursor-gradient-2', { attr: {"stop-color": '#000'} }); Does that clarify things? Oh, and you don't need to have this line: gsap.killTweensOf(['#cursor-gradient-1', '#cursor-gradient-2', '#cursor-fill-1', '#cursor-fill-2']); You can simple set overwrite: true or overwrite: "auto" on your tweens. I mean it's totally fine if you prefer explicitly killing things like that, but it seemed more verbose than necessary. Happy tweening!
  23. So, on click kill all ScrollTrigger's then scale to 100% and create a new ScrollTrigger (that does no animation). And that one has two hooks: on leave and leaveBack, that then kills it self and reinstates all previous ScrollTrigger's that where killed by the click? Seems a lot more complicated than `overwrite: true`, which if it would work does everything above, but with one line of code. Why doesn't overwrite work? Are there plans to make it work in combination with ScrollTrigger?
  24. How do I overwrite scrollTrigger with an other timeline that also scrollTo the element on click, but keep the scrollTrigger alive to use the `onLeave` trigger? I have a page with videos and on scrollTrigger enter the videos should play and scale a bit (✅ working), but then when the user clicks the video should scale to 100% (❌ not working). I've set the property `overwrite: true` on the time line, but that doesn't seem to work in combination with scrollTrigger. In my demo you can see an orange box that scales to 100% on click, the video tries to do the same, but is taken over by the scrollTrigger timeline which I want to overwrite. I've tried killing all the scrollTriggers, but I need the `onLeave` trigger for when the user scrolls away again, so I can scale the video back and pause the video
  25. Hello, In my react application, there are three section with class .cts which contains image and some content. All the three section is wrapped in a main container. Now I have implemented the animation as follow: const scrollColorElems = document.querySelectorAll(".cst"); scrollColorElems.forEach((colorSection, i) => { console.log(colorSection.clientTop); const prevColor = i === 0 ? "gray" : scrollColorElems[i - 1].dataset.scrollcolor; ScrollTrigger.create({ trigger: colorSection, start: "top center", end:"bottom center", markers:"true", onEnter: () => gsap.to("#ftiot", {backgroundColor: color, overwrite: 'auto'}) // onLeaveBack: () => onLeaveBack(prevColor), onEnterBack: () => gsap.to("#ftiot", {backgroundColor: color, overwrite: 'auto'}), }); }); Now the problem I am facing is the start marker keeps changing its position and become pretty inconsistent. In the below screenshot you can see the start marker is way below the top offset marked by black border of the trigger container even though I have specified "top center" as starting point in start property.
×