Jump to content
GreenSock

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


Forums

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

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge

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. Yikes! I totally missed this thread, @lucky111. Sorry! Yes, I would definitely recommend the helper function in the docs, no question. It will perform significantly better because it doesn't constantly create a new tween over and over again on each tick to accomplish the scrubbing technique. Plus the non-GreenSock one didn't set overwrite: true, so it was creating a lot of conflicting tweens. You'd probably never notice functionally, but it's bad for performance. It gives you a lot more flexibility, as mentioned above - you can add any ScrollTrigger-related value to the object you pass in. You're not limited to "fast", "medium" and "slow" speeds - you can set ANY end value, like end: "+=2000" or whatever. But it still works with speed if you prefer that syntax. So overall it's more concise, it performs much better, and offers way more flexibility. I don't mean that as a knock on Chris's version - he built that when he was very new to ScrollTrigger. We all know what a genius he is with animation in general - I just have an unfair advantage of knowing all the ins and outs of ScrollTrigger (having built it)
  2. Hm, it sounds like there may be some logic flaws in your code, but it's difficult to troubleshoot without a minimal demo. But I'll offer a few thoughts: It looks like you're reusing the same timeline instance over and over again and doing a clear() after it's done. That's not "wrong", but it's probably simpler to just create a new timeline each time (or if you're not sequencing things or need to control multiple as a whole, just skip the timeline altogether and use tweens). Remember that by default, when you add() something to the timeline, it gets added to the END of it. So let's say the user clicks multiple times quickly, that means your code is just sequencing the new ones after the current ones that haven't finished yet. See the problem? Or do you clear() it before running each time too? Again, it's tough to know by just looking at a small excerpt. You don't need to timeline.add(gsap.to(...)) - that's just a long way of using the convenience methods: // long timeline.add( gsap.to( ... )); // short timeline.to(...); Be careful about creating conflicting tweens where they're fighting to control the same property of the same object. You can set overwrite: true to have GSAP immediately kill all other tweens of those targets, or overwrite: "auto" to only kill the individual parts (properties) of the tweens that overlap. I'd rewrite your first block of code like this: // OLD let itemScrollTimeLine = gsap.timeline({ paused: true, onComplete: resetTimeline }); function resetTimeline() { console.log('Completed'); itemScrollTimeLine.clear(); } if (itemList.indexOf(elem.id) >= 0) { let elemPos = (window.innerHeight - document.getElementById(elem.id).offsetHeight) / 2; itemScrollTimeLine.add(gsap.to(window, { duration: 1.2, ease: "power1.inOut", scrollTo: { y: elem, offsetY: elemPos } })); } else { itemScrollTimeLine.add(gsap.to(window, { duration: 1.2, ease: "power1.inOut", scrollTo: { y: elem, offsetY: 100 } })); } itemScrollTimeLine.add(gsap.to(elem, { ease: "power3.inOut", duration: 0.8, '--line-color-top': '#a18248' }), '>'); // NEW let itemScrollTimeLine = gsap.timeline(); itemScrollTimeLine.to(window, { duration: 1.2, ease: "power1.inOut", overwrite: "auto", scrollTo: { y: elem, offsetY: itemList.indexOf(elem.id) >= 0 ? (window.innerHeight - document.getElementById(elem.id).offsetHeight) / 2 : 100 } }); itemScrollTimeLine.to(elem, { ease: "power3.inOut", overwrite: "auto", duration: 0.8, '--line-color-top': '#a18248' }); You really shouldn't need to getChildren() and remove() any of them. Ditch that altogether. I think that was more of a band-aid that was attempting to cover over the fundamental problem which had more to do with your reusing the same timeline and continuing to shove new tweens one-after-the-other or maybe overwriting (or lack thereof). If you're still having trouble, it'll greatly increase your chances of getting a solid answer if you can provide a minimal demo. Thanks for being a Club GreenSock member! 🙌 Happy tweening!
  3. The only thing I would add is to enable overwrite.... gsap.defaults({ overwrite: "auto" }); And modifiers need to return a unit. return (pressedTop ? -skew : skew) + "deg"; But it still a little weird. Probably just need to tweak some stuff.
  4. Thank you , You are super helpful and always get to the heart of the solution but I get how I made this slightly confusing. Yes I understand the overwrite issue. I was getting this issue with other solutions, For some reason it is not working on codepen (I will add it but hopefully it doesn't confuse you), but my html works, I could film it if needed. The reason I don't want to reverse is because I want to fade out immediately and quickly once the mouse leaves the box. The only issue is I don't know how to do this without waiting for the mouseenter timeline finishes. ... Is there a way to on mouseleave: kill/ pause the previous timeline and tween to an opacity 0. if this still doesn't make sense I can explain it differently, just let me know! Thanks! https://codepen.io/jaykobz/pen/YzNQBVm?editors=0010
  5. I don't have time to troubleshoot your whole project with various other frameworks that may be causing conflicts, but I can offer a few pointers: Make sure you're killing things off properly between pages. I bet you keep starting a requestAnimationFrame() loop over and over again on every page and it's building up and causing a very heavy load with conflicts and redundancies. This is very inefficient: // not good function mouseMove(e) { gsap.to(jsCursorCircle, { duration: 0.5, x: xPos, y: yPos }); gsap.to(jsCursorDot, { duration: 0.2, x: xPos, y: yPos }); requestAnimationFrame(mouseMove); } Roughly 60 times per second you're creating a new conflicting tween and you don't have overwrite: true set, so you'll end up having a ton of tweens running on the same thing simultaneously. At the very least, set overwrite: true on your tweens. I wouldn't use a requestAnimationFrame() either. You only need to run things when the pointer moves, right? And how are you killing that loop when you go to another page? (see #1) It's a bit more efficient to reuse the same tween instance in a case like this where you're doing a TON of them constantly: const cTween = gsap.to(jsCursorCircle, {duration: 0.5, x: xPos, y: yPos}); const dTween = gsap.to(jsCursorDot, {duration: 0.2, x: xPos, y: yPos}); function mouseMove(e) { cTween.invalidate(); dTween.invalidate(); cTween.vars.x = dTween.vars.x = xPos; cTween.vars.y = dTween.vars.y = yPos; cTween.restart(); dTween.restart(); } I hope that helps.
  6. Yep, it was a very intentional change because: The old "auto" default overwrite mode sometimes caught people off guard, so opting in ensures people are aware of what's going on. Overwriting costs some overhead processing-wise, but in the vast majority of cases you don't really need to do any overwriting so it's just a waste to always do by default. Even when you've got two competing tweens running, the "last one wins" rule applies so people almost never notice it anyway. The only time it becomes a stumbling block is when the new tween has a shorter duration than the old tween. That wouldn't work because the 5th parameter is the value that you want mapped. But like you said, it's quite easy to get the result you want: const convert = gsap.utils.pipe( gsap.utils.clamp(0, 1000), gsap.utils.mapRange(0, 1000, 2, 0.5) ); console.log(convert(-100)); // 2
  7. Hmm, it seemed to hold up well in my quick tests, but I don't doubt you. Have you tried removing all the custom velocity-based stuff? My suggestion would be to roll-back and get it working with more basic features and then see where it breaks. Unfortunately, I don't have the time to jump in there and do deep debugging. Glad you liked the overwrite video though! @GreenSock can speak better to the change in overwrite modes for GSAP 3. I'm pretty sure the default of true requires less overhead and better performance. Carl ps. good to know you are previously Kreativzirkel
  8. Cool! Very good video! Especially the real life example at the end is important in my opinion to drive the point home. I love it! So my assumption is right for gsap 2: there was an automatic overwrite. I'm wondering why you chose to set it to false by default? `auto` as the defaults feels like it makes more sense. Back to topic: unfortunately I can still provoke unwanted jumps/flashes in your pen when scrolling back and forth heavily
  9. Clever approach! Thanks for the demo. I set overwrite:true on the progress tween in the fork below. https://codepen.io/snorkltv/pen/QWdwyVg?editors=0010 Does that help? For more on overwriting check out: Handling Conflicting Tweens
  10. Hi @ZachSaucier, Thanks so much for that article, it really helped. I've looped it and it's much cleaner. How should I go about adjusting individual animations? eg let's say I wanted to change the duration of the second brush. I'll add an additional class to that element and then overwrite it? What's the cleanest way to do that? https://codepen.io/spearquit/pen/NWbVGJM
  11. Hey girro. Some notes: You're making one of the most common GSAP mistakes of using the old duration parameter instead of including the duration inside of the vars. Putting it in the vars also lets you use defaults. Your repeatRefresh isn't doing anything. If you're going ahead with some ES6 stuff (like arrow functions) you may as well use more features (like using const and let). If you're using a timeline we recommend using the position parameter instead of the delay property. We recommend using the latest GSAP version (3.6.0 at the moment). On CodePen, you should only include the stuff within the body in the HTML section. And you can load external resources via the cog icon next to JS (and CSS). I recommend adding a background rect to each button so that they're easier to click. As for your question, often times it's good to create animations ahead of time and use control methods (this is one of the tips to animate efficiently). However, if you need the animations to overwrite each other like this usually it's best to create the animation when you need it. I'd approach it like so: https://codepen.io/GreenSock/pen/GRNLwXE?editors=0010 With that being said, your timelines currently affect both state-specific elements and shared elements (like the background shape). The way I have it set up above, the animation is killed off completely when an item is clicked, which could be an issue if users click between them fast enough. To remedy that, I'd separate the state specific animations from the shared animations. Only kill off the animation(s) related to the shared elements and let the ones for each state continue.
  12. We don't really have the capacity to do code optimization for every person who posts in these forums. Glancing at the code I'd try to avoid creating functions inside of a loop if possible. I bet you could avoid having to get the BoundingClientRect every mouse move event. You should also make sure to overwrite the previous animations in GSAP 3. There's really not that many calculations going on - GSAP can't remove the need to avoid calculations in every case.
  13. That's TypeScript misinterpreting things - it doesn't understand what "this" is in that context. Totally unrelated to GSAP/Draggable. You could work around that like: let drag = Draggable.create('.scrollbar', { type: "x", bounds: ".scrollbarContainer", throwProps: true, onDrag() { gsap.to('.gallery', {x: -drag.x, overwrite: true}); } })[0];
  14. Hey TradingBo. You're making some of the most common GSAP mistakes — I recommend going through the article Also instead of a zero duration .to() we recommend using .set(). That is a very weird error... I don't know why that's happening. It seems to be due to something inside of CodePen itself - if you run the debug view of the pen it doesn't throw the error. As for your main question, creating two different animations (for the intro and exit) at the start and using control methods is a tricky situation. There are a few different methods you could use: Don't use two different animations - just use one and reverse it on exit. In a lot of cases this is a good option for these sorts of toggled animations. Use two different animations but generate them as needed. What I mean by this is that you could, when clicked to open, dynamically create an animation to run with the necessary end values (and optionally use a duration based on how far the value(s) need to change). Make sure to overwrite any previous animations applied to the targets. This would allow you to toggle the state while a previous animation is still running but it more work. Use two different animations but don't allow them to overlap. You can do this by either detecting if a previous animation is running (and don't do anything in the click event if so) or by using a single timeline and using .tweenTo() and labels. I talk more about the second way here in my article about animating efficiently (I highly recommend going through the whole thing).
  15. Hey Alle. The question really boils down to: what are you wanting to show? Are you wanting to show a value based on the actual load of the page? Or based on your animation length? Because the two almost certainly don't match up exactly. That distribution of values largely comes from the ease that's applied to your tween. If you set the ease to "none" it will be more what you're expecting. If I were tasked with doing something like this, I would probably use the method of calculating the estimated time of the page load that Ahsan provided in your linked post but use GSAP's ticker to update the value. Or perhaps using tweens that overwrite each other if you find that there are larger jumps that are unsightly.
  16. I had overwrite set to 'auto', when I set it to true the wonkiness goes way up, it doesn't even appear to be playing anymore. No, wait... true may have done it. I've also got it initially paused and played by scrolltrigger, and I think that was where the additional wonkiness was coming from.
  17. @billyZduke just a shot in the dark here, but have you tried setting the overwrite to true or auto? gsap.defaults({ overwrite: true }); Does that make any difference?
  18. Closer to a minimal demo Several notes: You're still using the super old version of GSAP. Again, we recommend upgrading. If you upgrade, you should also apply overwrite: 'auto' to your tween that animates the position of your circle. See this post for more info. If you remove the Locomotive Scroll part you can see that your code doesn't work in that case either. I don't really understand why you're using the setTimeouts. You should avoid container.getBoundingClientRect() from firing every tick if you can as it's not very performant. As I said in my first post in this thread, since Locomotive Scroll replaces the natural scroll you'll need to get the position of the scroll from Locomotive instead of from the default scroller of a page. In cases like this you need to see how the element is mispositioned (is it always a constant amount off? If so where is that constant amount coming from? Is it off by how much you scroll? If so you need to add in the scroll position to the calculation). If I were creating this I'd probably make the circle a child element of the section that you care about and position it absolutely. That makes the calculations easier, though it's definitely possible to do the way you have it. I've not used Locomotive Scroll too much. The only way that I'm aware of getting the scroll position is using the scroll event listener. There might be a better way (like a property on the locomotive instance) that you could do instead. https://codepen.io/GreenSock/pen/bGBjzvX?editors=0010
  19. Hey @ilike.idontlike, You could use overWrite: true overwrite If true, all tweens of the same targets will be killed immediately regardless of what properties they affect. Horizontal: Please look in the ScrollTrigger DOCS. And provide a reduced CodePen of your case. Then if you have a question, we'd be happy to help. Happy tweening ... Mikel
  20. Thanks for the clear demo! The simplest solution is to apply immediateRender: false to your tween that has the ScrollTrigger. https://codepen.io/GreenSock/pen/KKNZWWa?editors=0010 You might also want to use overwrite: 'auto' on the tween with the ScrollTrigger. Another solution is to use the onComplete of the tween that runs on load to create the tween and associated ScrollTrigger.
  21. I assume you're asking why your method works? It works because it's basically the same method that I suggested. Overwriting doesn't come into play because there are not conflicting tweens. But it's incorrect to add overwriting because if some overlap were introduced then it would break. As with most things, it depends. If you need to animate the same properties of the same target(s) at the same time and you want them to not overwrite each other then that's a case for using a container element. That way the effect is additive and there's no conflict.
  22. Hi, i've started my first project with greensock a few weeks ago, had some problems along the way, solved them with the help of the detailed documentation and by quietly reading in the forums. Big kudos to the Dev Team for creating such a fun and high quality library and also to the awesome and super helpful community! But now I'm at a stage where I'm a bit stuck. I've created a little landing page with three smiley faces (svg) that pop out and in on mouseEnter / mouseLeave To draw attention to the little guys, I made an "idle"-timeline that makes them move randomly as if they were rummaging through some stuff in their caves. On mouseEnter they should stop rummaging and pop out ("tl"-timeline). It generally works, but there is one issue that I don't know how to get rid of: I had to place an overwrite: true into the animations, otherwise the timeline animations mix and produce all kinds of weird behaviour. But this removes all X and Y random motions i've declared and only leave the rotation being executed. Is there any other way of circumventing the animations mixing that keeps X and Y moving?
  23. You're right, I could settle with only the rotation for the effect, but I like it more with the additional axis' and also I'm trying to learn :) I did try overwrite: "auto", but there's still glitches in the movement. To illustrate this better I made my minimal demo slightly less minimal and added the speech bubbles I have in my actual project. Try moving your cursor in and out of these to produce the animation glitches. https://codepen.io/jhtjards/pen/BaQwxGd
  24. Have you tried overwrite: "auto" it will try to detect if there are values that are still going which the tween doesn't affect, so it should leave those alone. Also why do you need other way. True seems to give good results as well. Other than that I am bit lost to what you want to achieve.
  25. Also, just to be clear, your example creates a huge memory leak and compounding performance problem because you're literally creating 60 new tweens per second (assuming 60fps) that are constantly repeating and fighting each other for control of the same property of the same element. Definitely don't do that! So after 1 minute, you've got 3,600 tweens all fighting (3,599 more tweens than you need). At the very least you should set overwrite: true to avoid the build-up, but there are definitely better ways to code that. I'm trying to understand why you were putting it in a requestAnimationFrame() and constantly creating new instances. I don't mean it as a criticism - I'm genuinely trying to wrap my head around your original goal so that I can better advise you about a more appropriate way to do it.
×