Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for 'overwrite'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


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

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website



Company Website



  1. Hey PG1. You shouldn't be splitting your elements every time the mouse enters and exits. Only split it at the start. Besides that, you're making one of the most common GSAP mistakes: creating .from() logic issues. You should probably use .fromTo()s in your burnIn instead. Fixing those issues, you should get something like this: https://codepen.io/GreenSock/pen/vYyEwxb?editors=0010 Note that I didn't fix the logical issue when a user hovers it in and out quickly before the animation completes. You'll have to decide what to do in that case - whether or overwrite the previous animation, whether to ignore it if the animation is completed, or something else. FYI animating filters is not very performant.
  2. Hi there I have set up some animation based on scroll through "enter & leave" state. Everything works as expected except when I scroll the page fast like by pressing the home or end button then animation will not complete and elements will overlap over each other. I searched on the forum and found the partial solution by using "overwrite: true". It made the animation complete but I am using scaling of elements in it that does not go back to it's original scale 1. Attached is the codepen for better understanding. Can someone pls explain what causing this behavior and how to prevent it so that when page is scrolled fast, the animation works all the way as supposed. Regards, Shehzad Asif
  3. Hey SntsDev. One option might be to add a default onUpdate callback to your tweens: gsap.defaults({ onUpdate: () => console.log("fires if tween is running") }); However if you overwrite the onUpdate in a tween then it wouldn't fire for that tween. Perhaps @GreenSock could help with another alternative.
  4. Hey Mike. Connecting all of these modes of navigation is not the easiest task as you have found out Using the scroll position as the "core" of all of your navigation as you're doing is the right way to go. Unfortunately debugging all of your functionality is a bit out of scope of what we're able to provide for free. There's definitely some logical issues going wrong here, probably related to how you're updating the scroll position on drag. You definitely need to make sure to overwrite any previous animations affecting the scroll position by using overwrite: 'auto' on the relevant tweens. What makes you think it will go into an infinite loop? The cosmetic state is not attached to the actual scroll position... You should be able to update the cosmetic state as often as you'd like.
  5. Yep, exactly - we've actually got 3 levels of GSAP-ing; we've got the raw timeline which is the base which has "extra" animations because we want things to be "infinite", so we can't start the animation at the very beginning - there won't be any elements showing to the LEFT of that first element. So, for example, if we've got 5 elements to animate, it'd look like: 1-2-3-4-5-1-2-3-4-5-1 ^ start here The "overlap" is just the number of elements on each side of the start/end that we'll pad it with (so we'll add 2 * overlap number of extra animations). It really just depends how many elements are shown on the screen at any given time. The goal: cover the extra space. Here the overlap is 3 (thus 6 extra animations tagged onto the end). The tighter the spacing, the more elements/animations you'll need to cover the gaps which is why I've got it set to Math.ceil(1 / spacing). We pause that timeline because we'll control its playhead with ANOTHER timeline we're creating - "seamlessLoop". As indicated above, we'll start at the first "extra" animation so that there's stuff to the left ("5-4-3..."). Then we tween forward by the "overlap" amount (3 here) at which point we jump the playhead backward that same spot in the "normal" set of animations (non-extra). 1-2-3-4-5-1-2-3-4-5-1 ^ <------ ^ jump from here Then it tweens forward to where we started, thus if you were to play the seamlessLoop timeline (which just contains two tweens that scrub the raw timeline's playhead), it'd appear to seamlessly loop the "raw" timeline. Cool, huh? Most people really struggle with figuring out how to do a seamless loop where elements go off one side of the screen and come in the other side later. If you can explain this approach well in your tutorial (or whatever), it might help a lot of developers. Smooth scrubbing So now we've got a seamless loop that'd play, but we want to link that playhead to the scrollbar and have it SMOOTHLY move to a new position whenever the user scrolls, so we create a simple "scrub" tween to handle that which we reuse over and over again whenever we're going to a new position. That's cheaper than creating a new tween instance on every update (which could be quite frequent while scrolling). No need to manage overwrites that way too. Snapping Since we spaced all the animations out on the "raw" timeline with the "spacing" value, and we set up our "seamlessLoop" to start at exactly the spot where the first element is in the middle of the screen, snapping is easy. If "spacing" is 0.1, for example, we know that element #2 will be centered on the screen at a time of 0.1, the third would be at 0.2, etc. So it's index * spacing. Infinite looping & "iteration" We set the seamlessLoop to a repeat: -1 to allow us to just keep pushing the totalTime forward however far we want, and the timeline handles the looping at the appropriate spots. I'm using scrub.vars.totalTime is the destination value for the scrubbing. It's a convenient way to keep track of that too. So when you hit the "next" or "previous" buttons, all we've gotta do is add/subtract whatever our "spacing" amount is to get to that next spot on the timeline. The only catch is that you can't really go backwards past 0 (the start of the timeline), so we sense that condition and shove the playhead forward 10 iterations (it could be any number, there's no reason it has to be 10). We need to track the "iteration" in order to appropriately handle the wrapping around for the infinite scrolling effect. Otherwise, think about what'd happen if you scrolled all the way down (progress: 1) and it shot you back to the start (progress: 0) - the scrub tween would end up REWINDING all that distance instead of acting like it's continuing forward. Note: I based everything off of a tween duration of 1 second. Originally I had that as a variable, but then I realized it's not very helpful. It seemed cleaner to just use 1 across the board, and then you can adjust the "spacing" variable for a different effect, and/or alter the tweens, of course, but there seemed no benefit to having yet another "duration" variable floating around. So if you see the value "1" in various spots, it's likely related to duration. The down side of your previous solution was that it had to run a bunch of logic and create a set of new tweens each and every time you reached a new "slot". If someone scrolls really fast, it's expensive and you were actually creating conflicting tweens (easily remedied by setting overwrite: true, but still). You'd also get inconsistent timing because imagine what'd happen if one of the elements is halfway to its destination, and then the user scrolls so now it's gotta go to a new destination...if you've got a duration of 0.5, for example, it'd move a lot faster if that spans 800px than if it spans 50px. So the spacing between things could get a bit inconsistent. If your tweens are fast enough, people probably wouldn't really notice. But I obsess about this stuff. When you use a single timeline like this, all the tweens are created ONCE and interpolation is very fast. Plus you get totally consistent spacing no matter how fast the user scrolls or clicks the buttons. Cheaper, faster, more accurate and consistent. 🎉 Answers to your comments in the code Regarding the onRepeat that works around a super rare edge case bug that's fixed GSAP 3.6.1 - I'd keep it in there because 3.6.1 isn't out yet, and people may use older versions. Without getting into the weeds too much, if you go backwards over a loop threshold in a paused timeline (before 3.6.1), it could render (just for that one time) at the very beginning of the iteration. Since our demo is constantly tweening that playhead (with "scrub" tween), there would be situations where going backwards past the first element would have that tween start at the wrong value because the tween happened to snag the starting value at just that moment, thus things would appear to go back a whole iteration. // There are two fromTo because the properties have a different duration. // We want the cards to appear quicker. No, it's just because we have some properties that yoyo from the right side of the screen to the left (opacity and scale, for example) so they get big until the center of the screen, then go back down whereas the "xPercent" tween is consistently decreasing that whole time. So we need TWO simultaneous tweens for all that. These are NOT obvious questions and I'm glad you asked. It's a relatively advanced concept. I don't think I've seen anyone else take this approach, but in my opinion it has a lot of merit. Phew! Longest post in a long time. But I'm excited about what has been accomplished here.
  6. So the overwrite:'auto' worked perfectly. However, I haven't applied any bounds to the joystick because the outer container is circular and not rectangular. So, I just added some logic to end drag if it is a particular distance from center. Hence, maxX and maxY is simply undefined.
  7. (In Animate CC) I have been at this for a while but cant figure out how to restart an animation from the beginning values when I use an overwrite. A basic example. On "tl2" timeline a symbol scales slowly from 0 to 100. After 3 seconds "tl" timeline overwrites and scales this symbol back to 0. Both of these timelines are nested inside a "maintl" that runs on a endless loop. In this case when "maintl" restarts the "tl2" symbol is not at 0 scale but at where it was cleared and scaled back to 0 by "tl". How to restart the "maintl" so that scaling starts again from 0. var maintl = gsap.timeline({repeat:-1}); var tl = gsap.timeline({repeat:0}); var tl2 = gsap.timeline({repeat:0}); //tl1 tl.to([this.ring],{duration:0.5, scale:0, ease:"none", overwrite:"auto"},"+=3"); tl2.to([this.ring],{duration:6, scale:2.5, ease:"none"},"+=0"); //maintl maintl.add(tl,0)//starts at time of 0 .add(tl2,0) Thanks in advance.
  8. Hey Narendra786 and welcome to the GreenSock forums. Currently every single time the onDrag function fires (which is a lot while users are dragging) you're creating a new tween that plays for its entire duration. That's not good. You should either use overwrite: 'auto' on that tween to make sure that it kills old tweens affecting the same properties of the same object or use a different approach like a more manual setting of the rotation probably using quickSetter (but you'd have to handle the easing and such yourself). To get the position, you will need the max distance in the x and y directions from the center point. Then you can use the current x and y along with those maxes to create a proportion. Then you can apply that proportion to your max velocity (or acceleration if you'd prefer) in the x and y directions to get a current velocity (or acceleration). Then you should apply that to your rocket.
  9. You can view what I did in the demo that I posted. From the tween vars docs: overwrite 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. That's @Carl's stuff
  10. This was copied from one of the videos with the "Freds". Do I just use .to or .from and drop the tl? Also, help me to understand what "overwrite" does in: gsap.defaults({overwrite: 'auto', duration: 1}); I couldn't find it in docs.
  11. Hey Ivan and welcome to the GreenSock forums. Thanks for supporting GreenSock with a Club GreenSock membership! These forums are for specific questions, not general questions to help fix logical issues in your project's code. With that being said, here are a few notes about how I'd approach the situation: If there are less than four items, I would not show your buttons or create any animations. I would create a variable that keeps track of the current index. I would create a function that you can pass in an index to and it will animate the items to have the item at that index at the top of the cart section. I would create event listeners for each button that either increments or decrements the index by 1 depending on the button and then calls the function from the last bullet. I probably would not have a single animation and animate through the progress but instead create a new tween each time (making sure to overwrite any old animation) so that you have more control over how the items are animated. Since your cart is a fixed width do you really need a resize function? Hopefully that's helpful. If you have a specific question, especially about GSAP, let us know and we'll do our best to help!
  12. Hey darkgr33n. Step by step process through creating this effect is kind of out of scope for these forums. These forums are focused on GSAP-specific questions and while you use GSAP, most of your question is more logical. So if you have GSAP-specific questions please ask With that being said, I likely would try laying things out with flexbox instead, since the layout you're wanting is built into flexbox - taking a given width and dividing it up into parts. Then you just have to animate the flex properties. If you are going to use your method I likely wouldn't do any reversing - I would use new .to() tweens each time you need to change state. Also make sure to overwrite old tweens when appropriate (overwrite: 'auto'). Alternatively you could try using the Flip plugin to transition between states.
  13. Hey David and welcome to the GreenSock forums. Good job so far! These forums are intended for specific questions about GSAP. Unfortunately we don't have the capacity to help fix the logic of every project that uses GSAP in some way. But here are some tips: Instead of creating a new animation every time a section is entered or left, I would try creating a single timeline all of your transitions at the start (and recreating it on resize) and animate through it instead. This will not only help fix logical issues but will be slightly better for performance. My article about animating efficiently talks more about that but there's not an example in it specifically applied to a slider like this. If you choose not to use a single timeline, you need to make sure to overwrite any conflicting animations that you have. The delay that you have when clicking buttons sometimes is because the animation doesn't get fired directly based on the click, it's based on the scroll position. And since you're animating the scroll position it can sometimes take some time to reach the point at which the animation should run. If you have a specific question please let us know and we'll do our best to help
  14. Hey ywlee. To add some additional info, GSAP's ticker is a way that you can do something every time GSAP updates. Yes, you could create the demo using tweens (making sure to overwrite old tweens each time the mouse moves) but it'd be slightly less performant. Since the mousemove event fires a lot when a user is moving their mouse around, it'd helpful to make things as performant as possible. In this case it probably makes more sense to use GSAP's ticker and quickSetter because it's more throttled and a little more performant. In general using GSAP's ticker is not "better" than using regular tweens. Regular tweens use GSAP's ticker under the hood. Whether or not you should use regular tweens or GSAP's ticker directly depends on what you're creating. In most cases regular tweens are best More or less. Sorry, I don't understand your question. Can you try to rephrase what you're asking? There's only one ticker. But you can add 3 different functions to GSAP's ticker, sure, no problem. But it might make more sense to use a single function and attach that to GSAP's ticker.
  15. That isn't true actually. The transform property contains data for ALL of the following: x, y, z, rotation, rotationX, rotationY, scaleX, scaleY, skewX, skewY, plus it has to handle the transform-origin in a particular way when applying certain transforms to work around various browser bugs and inconsistencies. So if you merely set "x" on an element, that doesn't somehow clear all the other transform-related values. In fact, that's one of the huge benefits of using GSAP for transforms - it lets you handle all those components independently. One tween could be only touching "x", while another animates "y" using a totally different ease. If you tried doing that in CSS or most other animation libraries, those would overwrite each other and they wouldn't be synchronized/combined at all. Also, we can't assume that elements begin with an identity matrix (no transforms). Plenty of people set things up with CSS that has transforms, thus GSAP must honor those. That's why the initial parsing is essential. It has nothing to do with clearProps, FYI. The worst thing you can do performance-wise is directly set/animate the "transform" property because it requires extra parsing to accommodate literally any value which could be a super complex, strung-together list of many transforms. It's much faster to use the GSAP shortcuts directly, like x, y, scaleX, scaleY, rotation, etc. You must be dealing with a LOT of elements if you're able to notice any difference. Typically the parsing is very fast and nobody would notice any impact in a real-world project.
  16. I'm trying to optimize things in my application. I use the tool in Chrome Dev tools -> Performance -> Record What I see that I have a fromTo GSAP animation which animates only one property for example "x". At the start of the animations GSAP reads the previously applied transform probably to maintain other at the original value, but this cause a recalculate style in special circumstances. I would like to tell GSAP that it does not need to read the previously set transforms, just overwrite every transform value with the one set in this tween. Do you have any suggestion what I could use? Here is an example what I used: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>CodePen - GSAP Basic fromTo Tween</title> <style> .box { width: 200px; height: 200px; background: red; } </style> </head> <body> <div class="box"></div> <script src='https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js'></script> <script> setTimeout(function () { const el = document.querySelector('.box'); el.style.left = '10px'; // Force recalculate style console.time("FromTo"); gsap.fromTo( el, { x: 0 }, { duration: 5, x: 500 } ); console.timeEnd("FromTo"); }, 2000); </script> </body> </html> This is how it looks in dev tools: In my real world application these recalculations affect the measured performance highly. If I would be able to prevent getComputedStyle() when fromTo tweens are used, I would be able to reduce the time spent with animation initializing about 50%
  17. Hey ywlee and welcome to the GreenSock forums. It can be overkill depending on what you're trying to do. At the least you should use overwriting inside of your tween(s) within the mousemove listener to make sure that old tweens are killed off like so: gsap.to(draggable, { duration: 1.2, x: `${event.clientX-50}`, y: `${event.clientY-25}`, overwrite: 'auto' }); If you're especially worried about performance, you could use GSAP's quickSetter instead. But then you need to handle the easing yourself. You could modify the mouse follower demo in the quickSetter docs to use the same sort of click and move logic that you have.
  18. When a tween renders for the first time, it records the starting and ending values internally so that it can interpolate between them SUPER fast (we obsess about performance around here). If, for example, your element's "x" is 0 when you created that tween and itemWidthRef.current is 500, then of course it would record that internally and start animating from 0 to 500. If the window resizes halfway through that tween, nothing changes for GSAP. There's no way it could possibly know that itemWidthRef.current changed since you fed it in as a string anyway. Plus it would significantly degrade performance if it had to check that end value on every tick and re-configure the interpolation. So it'll just keep going with the original values, ending at 500 as requested. So if you want to alter where that element is animating to when the window resizes, you can do any of the following: Create a new tween accordingly with the new end value. Simple and clean. It's best to set overwrite: "auto" or overwrite: true so that the old one doesn't keep running and conflict. invalidate() the original tween to force it to flush its start/end values and re-record them on the very next render. You'd also need to use a function-based value to make it dynamic, like x: () => "+=" + itemWidthRef.current. Also beware that if you want to keep the starting values, you'd of course need to rewind that tween before you invalidate() it so that it reverts to the starting values and thus when it re-records, those remain. Otherwise it'll use the current value as the starting value (like any normal tween does). You can also record the progress value if you want, and then re-apply it after you invalidate() so that things appear more seamless mid-tween. Does that help? If you still need some assistance, a minimal demo is the best next step. Happy tweening!
  19. I have one page scroll functionality. On scroll page jumps to top from random position. Sorry I'm without codepen right now. Maybe have you quick answer and you met this problem before? The link https://emelya.studio/storage/frame/ I'm scrolling with this code: function goToSection(panel, anim) { gsap.to(window, { scrollTo: {y: panel, autoKill: false}, duration: 2, overwrite: "auto", onComplete: () => { enableScroll(); } }); } gsap.utils.toArray(".map-slide-trigger").forEach((panel, i) => { ScrollTrigger.create({ trigger: panel, onEnter: () => goToSection(panel) }); ScrollTrigger.create({ trigger: panel, start: "bottom bottom", onEnterBack: () => goToSection(panel) }); });
  20. It's just a logic issue in your code - you're creating conflicting tweens that are fighting to control the same properties of the same object simultaneously. Your "out" tweens are only 0.3 seconds long, but your "in" tweens are 1 second long, thus think about what would happen if someone scrolls quickly. The "in" tween starts fading the element in, and then perhaps 0.1 seconds later you create ANOTHER tween that's fading the element out. So both tweens are running at the same time, fighting each other but the last one "wins". Then, when the fade-out finishes in this case, the fade-in still has 0.6 seconds left!! Thus it continues and you see the element finish fading in. GSAP is doing what it's supposed to do. All you'd need to do to fix this is set overwrite: true on your tweens (or you could do overwrite: "auto" but I think in this case it's cleaner/faster to just do true). https://codepen.io/GreenSock/pen/c51e08b1b31942b6a075181751836b6f?editors=0010 Side note: there's no reason to set scrub: true on your ScrollTrigger because that only applies if you actually have the ScrollTrigger controlling an animation. In your case, you don't. It's not hurting anything, but it's just unnecessary to have there. Happy tweening!
  21. Hey samlinck. This is because your tweens are in conflict with each other. Usually it's good to create animations beforehand but in this case it probably makes more sense to create a new animation each time an item is entered or left. If you do this you should make sure to overwrite the older animations: https://codepen.io/GreenSock/pen/NWRaxRW?editors=0010
  22. Welcome to the forums and the wonderful world of GSAP, @miketwalker. You just need to base your timing off the number of elements you're staggering. Here's a corrected fork of your codepen: https://codepen.io/GreenSock/pen/2cebe760d96fd703c4a19002bf415d86?editors=0010 And there's an alternate approach that uses keyframes and a loop in there in case that seems more intuitive for you. Either one is fine. It's just that in some cases, it can get a little mind-bending to work out lots of timing stuff in multiple staggered animations on the same elements so it can make more sense to just do one sequence at a time, and lay those out individually on a timeline chunk by chunk. There are actually lots of ways you could approach this. Here's one more that uses a modular function so you can just focus on one at a time: function test() { var div = gsap.utils.toArray(".textdiv"), stagger = 2, tl = gsap.timeline(); // loop through and for each element, feed it to slideDown and insert the resulting animation into the timeline in a staggered way div.forEach((el, i) => tl.add(slideDown(el), i * stagger)); } function slideDown(element) { var tl = gsap.timeline(); gsap.set(element, {xPercent:-50, left:"50%", opacity: 0, yPercent:100, top:"0%", position: "absolute", overwrite: true}); tl.to(element, {opacity: 1, duration: 2}) .to(element, {yPercent: -100, top: "100%", duration: 12, ease: "none"}, 0) .to(element, {opacity: 0, duration: 2}, "-=2"); return tl; } Happy tweening!
  23. Yes - sure does. I figured this was probably an edge case given GSAP's user base and the fact I couldn't see anything on it. Now I know what to look for I wont have the same issue in future. Understand and agree it probably doesn't warrant addition in the doc's. Hopefully if (in the unlikely event) someone manages to repeat my mistake googling: Keywords: added properties delay duration ease overwrite repeat will lead them to this explanation anyway. Thanks for the reponses everyone.
  24. Hi, I wouldn't consider it a bug. Keep in mind that a zero duration tween is not a distinctive GSAP instance on it's own, just a regular GSAP instance with duration zero. The .set() method is just a shortand/convenience in order to make it easier on developers to write, read and maintain code, because once you get used to the API it's simpler to understand this: gsap.set(element, {config}) than this: gsap.to(element, {duration: 0, config}), if another developer in a team looks at the second example the first thing is: Why this animation has a duration of 0 seconds? If the set() method is confusing the dev can come to the API docs, check it and realize that it creates a zero seconds tween. With that in mind and not knowing all the ins and outs of the codebase, perhaps that this happens in one of this places in the code: https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L307-L352 https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L1115-L1130 Or somewhere else ... Now I have used several times the approach you're using of creating a re-usable config object, but I never took the time to inspect it after GSAP used it, because it never led to any unexpected behaviour. Keep in mind that most commonly objects are passed by reference so given the parts of the code I linked above is quite expected that the original object would be modified. Is this modification leading to some issue in your code? I'd expect that if you overwrite any of the properties added by GSAP the one that you add would take precedence over the ones added by GSAP since those are there just as defaults. Finally I believe that either @GreenSock or @ZachSaucier are in a better position to give you a more "official" answer. Happy Tweening!!!
  25. Hey! I have the same divs with classes called "wrapper" and they both have same elements called "box" inside. When you mouseenter "wrapper" all boxes inside getting filter:grayscale(1) and autoAlpha:0.5 by tween, but also I have another tween which is saying that box that you target must be filter:grayscale(0) and autoAlpha:1. So my problem is that I can't overwrite first tween by second properly, if I add overwrite:true inside tween2 my function will not work at all. What am I doing wrong? Can you help me, please?