Search the Community
Showing results for 'overwrite'.
-
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.
-
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%
-
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.
-
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!
- 1 reply
-
- 2
-
-
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) }); });
-
Leave animation not triggering when scrolled fast.
GreenSock replied to Rinku Samanta's topic in GSAP
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! -
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 -
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!
-
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.
-
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!!!
-
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?
-
You can just animate the progress. And you don't need to use a timeline - just use a simple fromTo() tween for each direction: https://codepen.io/GreenSock/pen/5bab7669c11ef8400b5b56f5939d2d59?editors=0010 Is that what you mean? Just don't forget the overwrite: true on at least one of the tweens, otherwise you'll create a bunch of overlapping/competing tweens on each mouse movement. Happy tweening!
-
Hi everybody! I've been reading all the threads in the search results and reviewing documentation but I'm just really new to this, green you might say. I'd like to disable the left/right animation on mobile or if it's easier, disable all of them if I can't isolate them. It might look really stupid reading what I've done below but I'd love some help please if possible. I just don't know what I'm doing. Thanks in advance! ScrollTrigger.saveStyles(".gs_reveal_fromLeft, .gs_reveal_fromRight, .gs_reveal"); ScrollTrigger.matchMedia({ // desktop "(min-width: 800px)": function() { //Reveal Animations Scrolltrigger function animateFrom(elem, direction) { direction = direction | 1; var x = 0, y = direction * 100; if(elem.classList.contains("gs_reveal_fromLeft")) { x = -100; y = 0; } else if(elem.classList.contains("gs_reveal_fromRight")) { x = 100; y = 0; } gsap.fromTo(elem, {x: x, y: y, autoAlpha: 0}, { duration: 1.25, x: 0, y: 0, autoAlpha: 1, ease: "expo", overwrite: "auto" }); } }, // mobile "(max-width: 799px)": function() { return function() { gsap.kill(); // other cleanup code can go here. }; } }, // all "all": function() { function hide(elem) { gsap.set(elem, {autoAlpha: 0}); } document.addEventListener("DOMContentLoaded", function() { gsap.registerPlugin(ScrollTrigger); gsap.utils.toArray(".gs_reveal").forEach(function(elem) { hide(elem); // assure that the element is hidden when scrolled into view ScrollTrigger.create({ trigger: elem, onEnter: function() { animateFrom(elem) }, onEnterBack: function() { animateFrom(elem, -1) }, onLeave: function() { hide(elem) } // assure that the element is hidden when scrolled into view }); }); }); } );
-
thank you for your feedback @ZachSaucier Something like that i was waiting for yep i really have to learn the full power of gsap to not fall back to jquery without any need of it - actually while reading your feedback i have no clue, what i could address to gsap instead of jquery but i will check that this is a good point, will also check that - btw. i meantioned to not have an idea, how to react on window resize. Is the only way to overwrite the whole timelime to change vh and vw used in the timeline? how to get timeline direction without asking timeline._ts? ok - i saw both on my readings and string form felt wrong in any way what do you mean? again jquery? or what is this related to? is there any special you would to address to ES6? as i have to support IE11 i cant use ES6 - does i?
-
scroll-snap and ScrollToPlugin not playing nice togehter?
katerlouis replied to katerlouis's topic in GSAP
Thanks! Feared so. What is `overwrite: 'auto'` doing in your scrollTween? Also thanks for the idea of killing the tween when `wheel` event is triggered. -
Hey guys! I have been lurking the forum since last few days. I have found a lot of useful information thanks for the great support. I am looking to smoothen the animation in my codepen by doing following: - fasten the timescale of tweens when 'onmouseover' so the div stop quickly but gracefully - Also smothen the tweening overwrite happening while moving the cursor fast I think the best way would be to use a timeline to update timescale but I am having trouble to figuring that out. Thanks in advance
-
Hey Pata. Tweens aren't meant to be changed too much after they have been created. Instead of creating a ScrollTrigger with an animation attached to it, I'd create a ScrollTrigger with no animation and then create a new tween inside of the onEnter. Something like this (untested): ScrollTrigger.create({ trigger: '#footer', start: 'top bottom', toggleActions: 'play pause resume reset', onEnter: self => { const velocity = self.getVelocity(); const variation = velocity / 10000; const footerBounce = gsap.to('#down', { duration: 2, morphSVG: '#up', ease: `elastic.out(${1 + variation}, ${1 - variation})`, overwrite: 'auto' // make sure old tweens are killed }) } })
-
So I'm implementing a smooth scroll like this: useEffect(() => { const container = document.querySelector(".scroll-container"); document.body.style.height = container.scrollHeight + "px"; const onScroll = () => { gsap.timeline() .to(".scroll-container", { y: -pageYOffset, overwrite: "auto" }, 0) } document.addEventListener("scroll", onScroll) }, []) The smooth scroll is working fine, but its height is not being calculated properly. In other words, the scrollHeight I get from the container, won't be enough to scroll the whole container using smooth scroll. How do I calculate the height I need for smooth scroll?
-
Another alternative is to use a completely different approach: Position the cursor element in the center of the pink element. Set its scale to 0. In the mouseenter of the pink section, animate the cursor element's scale to its normal scale. In the mousemove of the pink section, animate the position of the cursor to the mouse position. Make sure to overwrite any animations affecting the position of the cursor element. In the mouseleave of the pink section, animate the cursor element's scale back to 0 and its position back to 0, 0.
-
Hey Coopski and welcome to the GreenSock forums. You're making one of the most common ScrollTrigger mistakes: nesting ScrollTrigger in tweens within a timeline. Doing so doesn't make much sense because the timeline and the ScrollTrigger try to control the animation. Once you fix that, you still have a logical error though: since your ScrollTrigger start point is before the initial scroll position, both your start animation and your ScrollTrigger are trying to set the value at the same time so one will overwrite the other. You probably want to wait to create the ScrollTrigger until after the load animation has finished. To prevent the jump in state caused by the initial scroll position affecting the ScrollTrigger, you could use a numerical scrub. Something like this: https://codepen.io/GreenSock/pen/mdEKYgE?editors=0010
-
Hey @imChris, It could be a questions of positioning (more here) e.g. try timeline.to(boxInner, { x: sectionMovement.getAttribute('data-x'), ease: animationEase, //overwrite: 'auto' },0) Happy precise timing ... Mikel
-
Hey Zach, Superb! That's exactly the effect I was looking for -- and has also given me a couple of new pointers for the future too. It makes total sense - I wasn't aware you could a) attach a tween to the onEnter/onLeaveBack calls in that way and b) hadn't properly grasped the impact/usage of the "overwrite:true" prop to kill the tween either. I'll make sure I do some reading around that one Many thanks (again!). Cheers!
-
Okay, thanks again for your help. Looking at this a bit more, I agree with you on the necessity of the overwrite because I'm not really seeing a way around that. I may end up going that direction.
-
ScrollTrigger and Draggable with mixed horizontal/vertical scroll sections
ZachSaucier replied to Pixouls's topic in GSAP
Unfortunately we don't have the capacity to make every edge case meet your needs. I would say the overwrite is pretty necessary to prevent the conflicts. Best of luck getting it working the way you need it to be working! -
Thanks for your reply and suggestions, Zach! Much appreciated. Those changes have brought me very close to a solution. On touch devices, I am still having a few issues, however. Basically, if the Draggable section is part way in the viewport, and the user tries to grab it and scroll back up, Draggable events are firing and the user can't really scroll up normally. I messed around with a few options using the deltas and Draggable.enable()/disable(), but can't quite get it - basically I would need a way to disable Draggable if the user is scrolling vertically. As a side note, I did have to remove the overwrite: 'auto' on the updateProxy function or else that will kill the inertia movements. And related to that, when inertia movements are still going and a touch user tries to grab the screen to stop, a bunch of flickering starts happening as the native scroll position and the inertia movements are fighting. I suppose this is where the overwrite would come in handy, but I would really like to have the inertia preserved if possible - do you happen to have any additional ideas on that? Thank you again for your help!
