Search the Community
Showing results for 'overwrite'.
-
thanks Zach for clarifying this to me and for quick response. I have a problem with property: repeatRefresh, i can't make it work. I'm trying to make a demo in which the svg paths will go in random directions using the new GSAP 3.x Utility Methods. I thought first the problem is with overwrite, but it's not. https://codepen.io/isladjan/full/qBEJPpJ
-
Hey isladjan, welcome to the GreenSock forums! This is a good question. Sorry, we're still in the process of updating our docs (it's a long process to document all of the changes and new things!) so onInterrupt is not in there yet. The GSAP 3 Release Notes say This means that onInterrupt only fires if the tween is effectively killed, meaning something like .kill() is used on it or another tween affecting the same target has overwrite: true. It might be worth observing how the different overwrite values affect your animation: https://codepen.io/GreenSock/pen/WNbaoXG?editors=0010 Are you trying to achieve something specifically? Maybe some context can help you figure out the setup that you need.
-
Hi to all, I'm trying to learn gsap 3.x, but i have a problem with overwrite. Can anyone show me working example of new "onInterrupt" callback? Or there is some other way in GSAP 3.x to identify when (or if) overwrite between tweens is happen? Thanks, isladjan
-
Good questions! A key to my demo is widthSoFar. Perhaps I should have named it something more appropriate for what it does, like offsetAmount. But naming things is hard and it's just a demo so I didn't think about it too hard. Anyway, its a variable used to keep track of the total amount of offset that accrues when users click the button and moves the "slides". Notice that it's the only thing that's being added to. All the tweens I create use it as a reference point. The purpose for this is that if someone clicks the button multiple times in a row (i.e. before the previous animation ends) you need to keep track of the remaining distance that hasn't been covered until that point. The reason why overwrite: true is required is because we want the old animations to be killed. We can't have the container being controlled by two tweens at once and the newer tween has the correct end point because it compensates for both the previous tween(s) and the new tween. Does that make sense? One other note, I included this bit if(!tweenAnim.isActive()) { widthSoFar = 0; gsap.set(container, {x: widthSoFar}); } Because I found that there was a small error in the offset if the user clicks a lot of times in direct succession. Evidently there's some error due to the small amount of processing time it takes to update variables (meaning the time between the click event and when the amount is actually stored in widthSoFar). So I corrected that by resetting once the animation is no longer active. I hope that helps! I'm happy to clarify anything that's confusing.
-
@ZachSaucier first of all, thank you so much. I was struggling with that all day! I originally removed the element from the DOM and used append child to add it to the end but I was constantly getting that jump. I would be really, greatful if you could answer these questions so I can wrap my head around what you did: How is it that cloning then appending doesn't create a jump? Ive never seen overwrite: true before, Ive read that: What's it doing in this tween? You've added a !tweenAnim.isActive() statement, which I presume is to set the container back to the starting position? How is it that you can click repeatedly and the tween still run smoothly? Again thank you so much.
-
So fast answer! Thanks!!! I can't find property overwrite in docs? Can you give me the link?
-
Your mouseout is triggering and you didn't tell your tweens to overwrite, so you're creating a ton of conflicting tweens. I assume this is what you wanted, right?: https://codepen.io/GreenSock/pen/9a468c836762b983013294fef9d7a296?editors=0010 Happy tweening!
-
Hm, try making sure you set overwrite: true or overwrite: "auto" on your tween so that it kills any competing tweens. If you're still having trouble, please post a reduced test case in codepen and we'd be happy to help.
-
I had to deal with this "issue" as well, I didn't go through entire code but for some reason ScrollMagic tries to update tween twice, then detects it as overwrite and tries to call onOverwrite method which has been removed from gsap 3. Certainly not related to GSAP and those are just warnings, you can ignore them without any issue. There are other compatibility issues, for example ScrollMagic tries to use 'Tween' object when you try to update scene duration on the fly, this gives error. You can set Tween equal to gsap directly in ScrollMagic files.
-
@ZachSaucier thanks for reply. I made a repro - https://codesandbox.io/s/jovial-moser-fk4lq Animations are in the App.vue file. If you change GSAP 3 to GSAP 2 all is fine. This behavior is not expected. I am not sure how to apply gsap.defaults({overwrite: "auto"})
-
Hey bdrtsky, It's hard to say from that video what exactly is happening. My guess is that it has to do with the default overwrite behavior. Try setting gsap.defaults({overwrite: "auto"}); and see if that fixes the issue. If it does, you can just set it on the tweens that need it later on if you want to. If it doesn't fix the issue, recreating the issue in a CodePen or something would be helpful for us.
-
Been struggling with this for a while now and can't seem to solve the issue. My animation has a box comes in from right (outside the 'banner' container) then the next tween needs to overlap and slow down the animation. .from(div1, {duration: 0.3, x: 300}, 'f1+=0.5') .to(div1, {duration: 6, x: '-=40'}, '>-=0.5') 2 sec later the next tween pushed the box out to the left. The problem is that on repeat the slow tween doesn't play. .to(div1, {duration: 0.3, x: -410, overwrite: 'auto'}, 'out1') If I remove the overwrite: 'auto' then the slow tween keeps playing after the box goes off to the left. Any suggestions? The only way I found a way around this to add a .call function https://codepen.io/dev-pk/pen/MWYJGEG
-
Thanks for clarifying what you're wanting. There are a few ways to handle this sort of thing. One would be to call the "out" animation/timeline then in its onComplete you do the "in" animation. That way when the other button is clicked, you overwrite the onComplete with the new animation. Any other method of waiting for the "out" animation to complete and then calling the correct animation would work. The selectors of this are a bit off but it shows the gist: https://codepen.io/GreenSock/pen/MWYyMmX?editors=0010
-
Not sure. I really haven't used any beyond simple testing in a long time, so I don't remember. It's mostly been helping other people. When something looks funky, it's not obvious to me that the problem is overwrite. My first instinct is that there is a logic problem somewhere. Also, callbacks fire on conflicting tweens.
-
Yep, we expected there'd be some speed bumps during the transition. Just keep in mind: No other animation engine I know of has ever done auto-overwriting (or any kind of overwriting that I can remember). So having overwrite: false as the default seems common/expected in the greater context (outside legacy GSAP) There's a performance penalty to overwrite: "auto". I'm not excited about imposing that on everyone, especially since I'd guess that 95%+ of users don't create conflicting tweens to begin with. In other words, a tiny portion of the audience benefits from something that 100% would pay the performance penalty for. Frankly, I'm a bit uncomfortable making it EASIER for people to create conflicting animations (without even realizing it) In some ways, I see it as a GOOD thing that some people have run into issues with their animations due to their conflicting tweens - yes, it's one more question in the forums for us moderators to answer, but ultimately it helps users understand what's going on and why they should avoid creating conflicts (or at least how to mitigate them intentionally if they must create them to begin with). I'm not totally closed off to changing the default to "auto", but I think we need to push through at least another month or two and let people settle in a bit. It seems premature to revert just because some people have stumbled. Remember, plenty of people have stumbled on the old default overwrite:"auto" behavior and wondered why their tweens got killed. It isn't as if overwrite: "auto" is going to solve everything. Wouldn't that be the case with any other animation library as well? And I'm curious - what are the common scenarios that tend to trip you up? I think it'd help me to understand the context a bit. In other words, when does the overwrite: false behavior tend to catch you off-guard?
-
I think having overwrite set to false is really only helpful to people who create conflicting animations in banner-like animations. When doing interactive animations, having overwrite set to false can really mess people up because most people are not familiar with the different overwrite behaviors. I've been using gsap since 2014, and the new overwrite behavior still messes me up. I looked at this question last night, and it didn't occur to me that it might be an overwrite issue. I understand the reasoning for having overwrite set to false, but I think it does more harm than good.
-
Hey mapo and welcome to the GreenSock forums! Thanks for being a Shockingly Green member. I think most of your jumpiness comes from the difference in the default value of overwrite between GSAP 2 and GSAP 3. In GSAP 2 it was "auto" by default and in GSAP 3 it is false by default. Changing it removes a bit of the jumpiness for me. You can change the default by saying gsap.defaults({overwrite: "auto"}); or you could apply it to just the tweens you want to by saying overwrite: "auto" in their vars parameter. @GreenSock another instance where people are tripping over this. But maybe it will lessen once people are converting GSAP 2 things to GSAP 3 a while from now?
-
Just keep bothering @GreenSock until he changes it back to "auto". ? There have been a lot of overwrite issues since v3 was released. https://greensock.com/search/?&q=overwrite&page=1&search_and_or=or&sortby=newest
-
HO, "auto" look fixed the issue here and also a lot of other issue in my core, i guess it was the solution. gsap2 was overwrite:"auto" by default ! and gsap3 was false by default ! **** why i didn't see this before!!! I think I just found the holy grail of all my hell problems with my events in gsap3. ??
-
Hey is this a bug or a misunderstood feature. I have issue with overwrite. In this demo if we make {overwrite:true} The timeLineId 'action' should override the timeLineId 'pre' only at 3 seconde no ? And if we make {overwrite:false} The timeLine 'pre' will continue in background and make big spike after 'action'. https://codepen.io/djmisterjon/pen/VwwJeJQ would it be possible technically to make override only act when the child timeLine execute has 3 seconds? thanks for help or suggest.
-
That's what I thought but I didn't want to assume anything In both line 46 and 47 you are affecting the same element's width. In the second tween (line 47) you have a negative relative offset of '-=0.4' which means that the tweens overlap by 0.4 seconds. That means that the tweens are in conflict! GSAP has a hard time figuring out which value the width should be because it's being told two different things. With that being said, you can tell GSAP to ignore the width animation until it has full access by setting overwrite: "none" on the second tween (line 47). That seems to fix the issue. My question is why does it currently work the first time? I would think it would have that glitch every time without changing the overwrite for the second tween
-
I see. Thanks for explaining more clearly! Long story short you have conflicting tweens - some tweens are overwriting others. That's why the duration matters. With an appropriately short duration, the tweens can start after each other. With a longer one they conflict so GSAP has to try and figure out what to do. The ways to work around this are to either 1) change your times so there's not this conflict or 2) change GSAP's default overwrite to a different value that works for your setup. By testing, TweenLite.defaultOverwrite = "allOnStart"; seems to work with the longer duration. You can see other values at https://greensock.com/docs/v2/TweenLite/static.defaultOverwrite
-
Thank you so much! Setting the overwrite mode worked! Creating the tween looks like the best alternative so I tried using that, but React is crashing logging t.getAttribute is not a function. const animation = gsap.fromTo( circleId, { attr: { r: 1 }, transformOrigin: "center", }, { scale: 20, transformOrigin: "center", paused: true } ); animateIconEnter = () => animation.timeScale(1).play(); animateIconLeave = () => animation.timeScale(6).reverse(); Here's my codepen.
-
Welcome to the forums, @Kahlub! In GSAP 3, overwriting is false by default. You were creating conflicting tweens in this case - in the mouseenter you started a 3-second long animation but let's say the user moves their mouse off of it 1 second later, you're creating another 0.5 second animation of the SAME property of the SAME object, which of course works (both tweens are setting that property, but since the mouseleave was created later, it runs last, thus its values are what's seen while it's running), and then when that animation finishes the OTHER one is STILL RUNNING. So suddenly you see the jump. That's not a bug in GSAP - it's just a logic issue with your code. But don't worry, it's easy to fix. You have several options: 1) Just set overwrite: true on your tweens. That means that when the tween is created, it finds all other tweens of the same target and immediately kills them. No more conflicts! 2) You could manually accomplish that with gsap.killTweensOf(yourTarget) but I find it simpler to just set overwrite:true. 3) You could set the default overwrite mode to "auto" or true, like: gsap.defaults({overwrite:"auto"}); That will tell GSAP to automatically check the first time each tween renders and find any animations of the same property of the same target and kill just those pieces of the other tween(s). 4) You could create a single tween that you simply play()/reverse() in the mouseenter/mouseleave events. That's even more efficient (but GSAP is so fast it's not as if there's a performance problem with the way you're currently doing it - I just tend to be a performance nut). If you want the mouseenter animation to be longer, you can simply set the timeScale accordingly, sorta like: const animation = gsap.fromTo(...); //create your tween once, set paused:true animateIconEnter = () => animation.timeScale(1).play(); animateIconLeave = () => animation.timeScale(6).reverse(); Just an idea. Lots of flexibility Happy tweening!
