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. When creating new versions of demos for these forums, please use the "fork" button so that context is not lost for future readers of the thread. Your approach is fine. You might want to add overwriting so that new tweens kill off conflicting other ones: overwrite: 'auto'. You could also make use of GSAP's built in random functionality instead of adding your own which just (slightly) bloats your code: x: 'random(["-=50", "+=50"])'.
  2. In general you don't want to keep adding to the same timeline like that. You should usually either use control methods on animations created beforehand (usually this is preferable) or create new timelines if you need to, making sure to overwrite old tweens. You might learn a lot from my article about animating efficiently. As for ScrollTo not working, I'm guessing that the ScrollToPlugin is updating the scroll position of the page but your custom scrollbar is not working? If not, please explain. In any way, please create a minimal demo using something like CodePen or CodeSandbox if you'd like debugging help. Side notes: You're using some of the old syntax. We highly recommend using all new syntax. It's easy to upgrade! You should avoid animating properties like top and left. Instead animate x and y as they're more performant.
  3. Back to `overwrite:` ! That was what I was looking for! But then I don't get why my frist pen didn't work, there I had `overwrite: true` and it was in a timeline instead of straight up `gsap.to()`. I had it also `scrollTo:` the element on click, maybe that is the culprit? But I've modified your pen and everything seems to work fine. https://codepen.io/mvaneijgen/pen/wvozqJa?editors=1010
  4. Hi, I would like to set dynamically x transform on scroll on element in my marquee, but the render is not immediate, there lot of latency. That my different gsap definition. Do you have any solution ? this.duration = 40; this.timeLine = gsap.timeline({ repeat: -1, force3D: true }); // SCROLL EVENT document.addEventListener('scroll', debounce(() => { //console.log(this.currentX - n); let t = window.scrollY; let n = t - this.scrollPosition; //console.log('SCROLL', this.currentX - n); this.timeLine.fromTo(this.trainContentWrapper, { x: this.currentX, immediateRender: true }, { x: this.currentX - n, immediateRender: true, }) this.scrollPosition = t; }, 250)); //Timeline definition resize() { this.totalDistance = this.trainContentWrapper.getBoundingClientRect().width / 2; this.timeLine.to(this.trainContentWrapper, { x: -this.totalDistance, duration: this.duration, ease: "none", //overwrite: true, onUpdate: () => { this.currentX = gsap.getProperty('.train-content__wrapper', 'x'); } }); }
  5. @ZachSaucier I want ScrollTrigger to scale the elements and on click the element should scale to 100%. If I want the click 100% scale to happen I have to `.disable()` the SCROLL scrollTrigger otherwise it will overwrite the scale. Another scrollTrigger should then check if you `onLeave()` or `onLeaveBack()`, then it should scale back to some magic value and the SCROLL trigger should enable again. In the end I also want to have a close button, with scales it back from 100% and enables the scroll animation again. I've also made a screen recording explaining my issue in more detail: and the pen https://codepen.io/mvaneijgen/pen/LYbZwyM?editors=0110 Fair enough, but I'll start optimising code when I got a working version.
  6. Thank you! i was thinking about the container too, in my project im using gatsy img (i know we already discussed about "framework" specific topics) and probably the rendred image alread have a wrapper i can "intercept" i will surely add the overwrite thanks again
  7. Hey popland. When creating something like this, you usually want to apply the mouse listeners on a container of the transformed element instead of the transformed element itself because that will make the mouse events less glitchy (i.e. if it rotates too much then the mouseleave will fire even though it's not outside of the original element's bounds). So in this case I'd probably make an empty element wrapper around each image. It'd likely also be easier if you use the native mouse event's layerX and layerY properties. These are relative to the element instead of the viewport which make calculating the angle from the center of your element a lot simpler. Lastly I highly recommend using overwrite: 'auto' on your tweens so that they kill off conflicting tweens (that way you don't have unnecessary processing being done). With those tips I think you can get it working the way that you want it to work. If you run into something you can't figure out feel free to ask.
  8. 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
  9. 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%
  10. It depends on the situation and what you need to animate from and to. You should use whatever method that you need at the appropriate time, whether it's .set(), .from(), .fromTo(), or .to(). Reading the docs is probably the best way to learn .set() sets the properties at that time. Defaults are just that - default values for tweens. They don't do anything unless you have a tween that the default gets applied to. And if you have the same property declared inside of a tween, it will overwrite the default value. Again, I encourage you to read about them There are various ways to do that sort of thing. As covered in my article about animating efficiently that I said you should read earlier, most of the time creating animations beforehand and using control methods is the way to go. Other times it might be appropriate to overwrite your old animations and make sure that you animate to the correct end values.
  11. We've had several people ask about this type of effect, so I just built a GSAP effect that makes this a lot simpler for you (or anyone). Here's a fork of your original CodePen with it in place: https://codepen.io/GreenSock/pen/oNYXzYB?editors=0010 So you can just paste that gsap.registerEffect(...) code into your project, and then it's super simple to make anything have that effect: gsap.effects.ticker(".hero__ticker-init"); That's it! You can control the speed and direction with attributes like: <div data-speed="8" data-direction="right"></div> I noticed a problem with your original implementation - if the screen was resized, it didn't adjust, so there could be gaps that showed up. The effect here automatically listens for "resize" events on the window, and dynamically adjusts. Seems to work relatively well. I haven't done tons of testing on this, but hopefully it's at least a good starting point for you. Here's the raw effect (you don't really have to understand it all to use it): gsap.registerEffect({ name: "ticker", effect(targets, config) { buildTickers({ targets: targets, clone: config.clone || (el => { let clone = el.children[0].cloneNode(true); el.insertBefore(clone, el.children[0]); return clone; }) }); function buildTickers(config, originals) { let tickers; if (originals && originals.clones) { // on window resizes, we should delete the old clones and reset the widths originals.clones.forEach(el => el && el.parentNode && el.parentNode.removeChild(el)); originals.forEach((el, i) => originals.inlineWidths[i] ? (el.style.width = originals.inlineWidths[i]) : el.style.removeProperty("width")); tickers = originals; } else { tickers = config.targets; } const clones = tickers.clones = [], inlineWidths = tickers.inlineWidths = []; tickers.forEach((el, index) => { inlineWidths[index] = el.style.width; el.style.width = "10000px"; // to let the children grow as much as necessary (otherwise it'll often be cropped to the viewport width) el.children[0].style.display = "inline-block"; let width = el.children[0].offsetWidth, cloneCount = Math.ceil(window.innerWidth / width), right = el.dataset.direction === "right", i; el.style.width = width * (cloneCount + 1) + "px"; for (i = 0; i < cloneCount; i++) { clones.push(config.clone(el)); } gsap.fromTo(el, { x: right ? -width : 0 }, { x: right ? 0 : -width, duration: width / 100 / parseFloat(el.dataset.speed || 1), repeat: -1, overwrite: "auto", ease: "none" }); }); // rerun on window resizes, otherwise there could be gaps if the user makes the window bigger. originals || window.addEventListener("resize", () => buildTickers(config, tickers)); } } }); Hopefully that gives you something that you can work with, or at least analyze some of the logic. Enjoy!
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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
  19. 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.
  20. 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!
  21. 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.
  22. 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
  23. 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.
  24. 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.
  25. 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.