Jump to content

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

GreenSock last won the day on September 27

GreenSock had the most liked content!


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by GreenSock

  1. Nah, you didn't do anything "wrong", but there are two key factors causing the confusion: There's a large startup cost on that very first frame when Pixi loads, creates the canvas, and basically does all its startup tasks. You can look at the delta that gets passed to the ticker listener (2nd parameter) - that first one is quite high. GSAP prioritizes time accuracy in the animations, thus it honors the amount that was elapsed, so for example if 150ms elapses before the next tick, you'll see that tween get rendered as if its playhead is at 150ms. That's the correct behavior. By default, there's a "power1.out" ease applied (for more natural looking movement), so movement will be quite a bit faster at the start of a tween and slow down at the end. You can set ease: "none" if you prefer a linear ease. In my opinion, the best solution here is to just use a single requestAnimationFrame() call to start your animations. So all your Pixi startup stuff will eat up resources on that first "tick"...and you use a requestAnimationFrame() to basically say "as soon as the browser takes a breath and goes to the next tick, start the animation(s)". Here's a fork: https://codepen.io/GreenSock/pen/75c11397af99ce0dc240ab801c361347?editors=0010 You could tweak the lagSmoothing() settings on the ticker if you want and that could definitely solve this as well, but that would apply to everything moving forward whereas this seems like merely a startup issue for you and the requestAnimationFrame() solution is quite simple. Does that clear things up?
  2. This is actually a great illustration of why DrawSVGPlugin is valuable. A lot of people think they can get the same effect by manually animating the strokeDashoffset which is technically true in many cases, but there are quite a few tricky things that the plugin solves for you and you just stumbled on one of them. Specifically, I noticed: You set the attribute with your function, but then you animated the CSS property. Be very careful because that ends up with there being two completely different values and some browsers prioritize CSS, and others may prioritize the attribute. In other words, how would you expect the browser to render this: <path stroke-dashoffset="320" style="stroke-dashoffset: 50px" /> More importantly, you used .getTotalLength() to get the path length which isn't always terribly accurate depending on the browser. In this case the real problem is that after you set that via the attribute, and then you tried animating it with GSAP (good), when GSAP tried to get the current value, the browser reported it slightly differently than what you set in the attribute via getComputedStyle(). Thus when you "rewind", the offset is slightly off, causing things to peek out. Here's a reworked version that uses DrawSVGPlugin. Notice there's less than half the code necessary: https://codepen.io/GreenSock/pen/133a8081ce0fcb6026f7e0b9386159ae?editors=0010 And it "just works". Here are a few things DrawSVGPlugin solves for you: If a non-scaling-stroke is applied, it will mess up your path's length Calling <path>.getTotalLength() in IE locks the repaint area of the stroke to whatever its current dimensions are on that frame/tick. Firefox has a bug that throws an error if the element isn't visible. Microsoft Edge has a bug that causes it not to redraw the path correctly if the stroke-linecap is anything other than "butt" (like "round") and it doesn't match the stroke-linejoin. Firefox doesn't always return an accurate getTotalLength(), causing things to be a bit short at times. Some browsers render artifacts if dash is 0. When the element has vector-effect="non-scaling-stroke" and the SVG is resized (like on a window resize), it actually changes the length of the stroke! DrawSVGPlugin can automatically adjust. A bug in Safari causes strokes with rounded ends to still show initially when they shouldn't. You can't getTotalLength() on other shapes besides a <path> (like a <rect>, <circle>, <line>, etc.) Again, that's part of what makes GSAP special - we try to figure out workarounds for all these things so your animations "just work". You're welcome to put together your own custom solution and it may work fine for your scenario, but hopefully all the time and headaches our bonus tools solve will make the membership pay for itself very quickly and ultimately make you more profitable as a developer. But there's no pressure to join, really. I hope that helps.
  3. It's because of a math issue in your code that's causing duration to be negative // if the window is less than 600, duration will flip negative! let duration = (window.innerWidth - 600) / 250; Perhaps you meant to wrap it in Math.abs()?
  4. That's because you're loading the wrong file - you're loading the ES Module The browser-ready ES5 (regular, non-fancy ES Modules) files are in a /dist/ directory: https://cdn.jsdelivr.net/npm/gsap@3.5.1/dist/PixiPlugin.min.js But why are you loading the main GSAP file from Cloudflare, and PixiPlugin from an entirely different place (JSDelivr)? I'd just stick with Cloudflare (same URL, just swap "PixiPlugin.min.js" for "gsap.min.js"): https://cdnjs.cloudflare.com/ajax/libs/gsap/3.5.1/PixiPlugin.min.js <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/3.5.1/gsap.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/3.5.1/PixiPlugin.min.js"></script> Better?
  5. It's pretty tough to diagnose blind, but performance issues like this are almost always completely unrelated to GSAP. I'd say that roughly 99% of the load on the browser is graphics rendering, not JavaScript code execution (GSAP). I'm also not sure what that $().explode() is, but that looks suspicious to me. If it uses jQuery animation, that's definitely rather slow (GSAP is up to 20x faster, but again, it's very likely not related to JS execution). Minor note: scale: 175 is definitely faster for GSAP than transform: 'scale(175)'. I'd strongly recommend using the transform component aliases like x, y, scale, rotation, etc. rather than the "transform" property which must get parsed every time. If you still need help, please post a minimal demo that shows the issue in context so we can see what's going on. Happy tweening!
  6. I don't think @krattus is saying it's a GSAP thing at all - it's just that iOS Safari throttles updates in non-activated iframes so the animations appear jerky (until you click into that iframe). It's totally unrelated to GSAP and the throttling affects requestAnimationFrame and setTimeout() (just like when you hide a tab), so I'm not aware of a workaround other than complaining to Apple or slapping a huge "CLICK HERE FOR SMOOTHER ANIMATION" image over the entire ifame.
  7. Just circling back on this because I've made a bunch of enhancements to the Flip plugin which renders some of my earlier comments incorrect. gsap.flip() won't return a timeline anymore - it'll return a Flip instance which has various properties/methods, one of which is "animation" (which is the timeline). So you can get it like gsap.flip(...).animation. I'll be documenting things for the official release, of course. I did update the demo I put in the earlier post.
  8. Also, here's a fork with the more complex functionality (extra button from your original): https://codepen.io/GreenSock/pen/aee24679fa5b33aed5617fab941a11ed?editors=0010 🎉
  9. Short answer: check out the new version of Flip that now lets you set "nested: true": https://codepen.io/GreenSock/pen/5e185bb47052e42b61f93687e29c00bf?editors=0010 Explanation: The challenge in what you were doing was that you had nested elements that were flipping, so when it looks at the end state and figures out where the elements are compared to where they were before the change (let's say container1 is 200px lower and child1 is also 200px lower), and it animates them accordingly. But of course if child1 is in container1, that means that for every pixel we move container1, child1 ALSO moves with it! So the delta of all the ancestor elements must be factored into the childrens' movement. Not a simple task...well, until now. Does that work the way you expected? (note: you may need to clear your cache).
  10. Nobody else has reported something similar and we're not aware of any issues, but I'd love to take a peek at a minimal demo to see what might be causing it in your scenario. Do you have markers: true on anything when the error occurs? (I'm trying to understand if it's ONLY happening when you have markers) Are you doing any DOM manipulation with the ScrollTrigger-related elements? Is there a chance that you [accidentally?] removed something that's supposed to be pinned?
  11. GreenSock

    Pause timiline

    If minimal code is what you're looking for, here's one other option: let shouldPause = true; let tl = gsap.timeline().to("h1", {x:300}) .add(() => shouldPause && tl.pause()) .to("h1", {y:300}); Just beware that when you do this kind of dynamic pausing, the pause may be slightly off time-wise because of the nature of updates. For example, if you place that function call at exactly 1 second into a timeline, remember that the timeline's playhead gets updated roughly once every 16.67ms and if the user's device gets bogged down it may be longer, so perhaps it updates at 998ms (before the pause) and the next update occurs at 1020ms for example - the timeline may actually get paused at a time of 1.02 seconds instead of exactly at 1 second. Normally that doesn't really matter, but I wanted to make sure I pointed it out. That's one of the reasons we have .addPause() in there to begin with - it forces the playhead to be EXACTLY at that spot even if the update is a bit late. There are ways we could adjust the code above to force that too, but I didn't want to make things overly complex when it probably doesn't even matter. Happy tweening!
  12. Have you tried a different iPad? It sure sounds like there's a problem with your iPad - it works fine on mine and I cannot imagine how/why it'd work fine on your iPhone (and my iPad) but not your iPad. It's iOS Safari on both, right? Or is one super old/outdated?
  13. I didn't quite understand your response. Are you saying you resolved the issue by using a server to avoid the browser's security restrictions?
  14. If I remember correctly, the styles can't be in external files (security restrictions imposed by the browser). In other words, <style>...</style> NOT <link rel="stylesheet" href="styles/layout.css">
  15. If you want to customize timings of various things that aren't directly related to positioning/size, that's easy - just do it with your own tweens. Remember, gsap.flip() returns a timeline, so you can even nest them in there if you want. In fact, you can return a tween/timeline in your change() function and it'll automatically nest that for you. And to be clear there was nothing fancy about that zIndex stuff where it was timing things to happen at exactly 50% through the animation. It's just that the zIndex was animating from 100 to 200 in one, and the inverse for the other, so of course they'd cross in the middle. Make sense? I'm not sure what you mean by "three phase", but to tell flip() what CSS properties to interpolate (beyond x/y and width/height or scaleX/scaleY), you just do a comma-delimited list like props: "zIndex,backgroundColor".
  16. I just checked on my iPad and it behaves the same as on my desktop. I do see animation (although it's a little odd because of how you have your start/end values set up). You should definitely remove the ScrollMagic indicators import. There is no "className" animations in GSAP 3 (at least not officially). That was removed because it's generally much faster to just define the specific properties you want to animate (rather than having GSAP loop through and compare literally every...single...property) and to save kb. If you really need it, there's an "unofficial" one here: https://codepen.io/GreenSock/pen/BaNRejV?editors=0010 Lastly, there's no need to define BOTH a scrub AND a toggleActions because toggleActions only apply to non-scrub ScrollTriggers. Logically it cannot be both. It doesn't hurt anything to have them both defined - ScrollTrigger will just ignore toggleActions if you have scrub declared. It's just unnecessary. Happy tweening!
  17. Apparently some browsers have started ignoring any zIndex updates that contain decimals. I'll update the next release to always force zIndex to round, but in the mean time you can simply add snap: { zIndex: 1 } to the flip() vars object (or any zIndex tween). Seems to work well in your demo: https://codepen.io/GreenSock/pen/43188ce41661f330ca8fdb1c176b62e1?editors=0010
  18. GreenSock

    VueJS Gsap

    Sounds like you just need to update to the latest version of ScrollTrigger/GSAP. You are probably using a version from before we added scrollerProxy(). 😁
  19. Ah, okay, that's because of the fact that apparently absolutely-positioned elements are still factored into the layout of flex parents unless they have a top or left specified. I forced that to happen in the latest Flip which seems to resolve the issue in your demo, right? (You may need to clear your cache).
  20. It's very difficult to troubleshoot without a minimal demo (like in CodePen), but my best guess is that you only changed "el" to this.$refs.container in one place, but you forgot to change it in the ScrollTrigger too, like trigger: this.$refs.container. If you still need some help, please provide a minimal demo. See https://greensock.com/demo for instructions. Happy tweening!
  21. Welcome to the forums, @AAP. We'd love to help, but there's not much we can do without a minimal demo we can look at (like in CodePen). If you'd like some help, please provide one. https://greensock.com/demo shows you how.
  22. It sure sounds like an issue with your build system/bundling. Unfortunately, there's really not much we can do to help if you just post snippets of the code that works locally. If you want help, you'd need to post a minimal demo that clearly shows the problem in a reproducible way. Perhaps try to simplify things into a stackblitz.com or codesandbox.io demo? Or something we can NPM install? But again, we really try to keep these forums focused on GSAP-specific questions and this sounds more like an issue with your build system so I'm not sure how much we can help. We'll do our best though once you provide something we can look at.