Jump to content

GreenSock last won the day on May 20

GreenSock had the most liked content!


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by GreenSock

  1. GreenSock

    wiggle path of SVG

    Looks like setting start:0 and taperStart:0 improves things, right @mikel?
  2. Oddly enough, I think it's actually doing precisely what it's supposed to be doing. Whenever GSAP senses an HSL value, it switches to animate in HSL so that it can keep those values "pure" (if you animate HSL values in an RGB way, it looks very different and is typically undesirable). But of course those animate around the color wheel differently (it's NOT just taking the red, green, and blue and animating those linearly). Again, this is all by design. Here's a demo that shows the HSL values and then their converted RGB counterparts: https://codepen.io/GreenSock/pen/67ccc31471f41af5a36d3a7b9d209a75?editors=0010 (Crack open the console to see). It's using ModifiersPlugin to just intercept things just before they're applied. See what's happening? The HSL values are indeed animating exactly as they should, and then the browser converts them back to RGB which is fine. Again, this is merely a side effect of how HSL values animate compared to RGB. Does that clear things up? If you don't want to animate things in HSL, you could convert them into RGB before feeding them into the tween. This page might be useful: https://css-tricks.com/converting-color-spaces-in-javascript/
  3. I don't really have time to pull it all apart, but I don't see anything obviously "wrong". You might want to try removing the canvas stuff (just for testing), especially the globalCompositeOperation = 'lighter'. It also looke like you've got a bunch of calls to particleTwo() and some drawing stuff that might be slightly problematic (not sure). I'd be curious about removing your calls to drawTwo() just to see how that affects things.
  4. Sorry to hear about the trouble, @Bradley Lancaster. I don't have any specific tools outside Chrome's dev tools and watching the frame rate and I think there are some CPU usage things there too, but it's tied to your particular system. In other words, it might be 8% on your powerful system, but on a cheap phone it's 90%. It's all relative. I'm curious - do your banners use SVG? That can be pretty CPU-intensive to render.
  5. Yep, it's an optimization based on whether or not there are multiple targets. Glad things are working well in the new version. Cheers!
  6. Ah, very interesting. Good catch. It looks like those two values are inverted. I can update the next release which you can preview (uncompressed) here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js In the mean time, you could edit the TweenLite.prototype like this: TweenLite.prototype.invalidate = function() { if (this._notifyPluginsOfEnabled) { TweenLite._onPluginEvent("_onDisable", this); } var t = this._time; this._firstPT = this._overwrittenProps = this._startAt = this._onUpdate = null; this._notifyPluginsOfEnabled = this._active = this._lazy = false; this._propLookup = (this._targets) ? [] : {}; com.greensock.core.Animation.prototype.invalidate.call(this); if (this.vars.immediateRender) { this._time = -0.00000001; this.render(t, false, this.vars.lazy !== false); } return this; } Just drop this in once after you load GSAP and it should resolve things. Thanks again for the reduced test case. Very helpful!
  7. I'm not a React guy (@Rodrigo is our resident expert, and he authored that article you linked to), but my guess is that your problem is that you're creating the tween in the componentDidMount(), but then you're playing that same tween again and again in the componentDidUpdate() method. Remember, the first time a tween renders, it internally records the starting/ending values so that it can very efficiently interpolate on each "tick". Your updates are having no effect. Instead of just play()-ing that same tween instance in your componentDidUpdate(), I'd create a new one and feed in the new x/y values. The new tween will overwrite the old one anyway. Does that help at all? If you're still having trouble, it'd help a lot if you provide a reduced test case in codepen or stackblitz or something like that. Happy tweening!
  8. I'm having a very difficult time understanding your question. Your example code assigns the same timeline instance to a bunch of objects in a "car" array. Literally, they're all pointing to ONE timeline instance. Perhaps that's a problem (I have no idea because I don't know what you're trying to do). Your second example code just has several to() calls and the position parameter isn't used, so they're sequenced by default (one-after-the-other). If you want to position them so that they all start at the same time in the timeline, then simply use the position parameter to define the time you want them to start. For example: tl.to(obj, 1, {x:100}, 0); //<- the last parameter, 0, is the position. tl.to(obj2, 1, {y:100}, 0) ... If you still need help, please provide more details about what you're looking to do and/or provide a codepen demo. It's very difficult to troubleshoot based on a small excerpt of code pasted in here. I'd really like to help you, but I'm not sure how because I don't understand what you're asking.
  9. Here's a fork: https://codepen.io/GreenSock/pen/56d8637f74c4afdc9fd02829b15682e3?editors=0010 Is that what you were looking for? (well, I tweaked the timing a bit and added a "y" tween just for fun).
  10. Howdy, @DeltaFrog. Yeah, if I understand your goal correctly, it should be pretty easy with SplitText. All you've gotta do is load the SplitText file (and GSAP, like maybe the TweenMax.min.js file) and write your animation code in a <script> tag. Does that answer your question? Is there something in particular you needed help with (GSAP-related)?
  11. Cool animations, @Killerwork! The CPU problem is likely caused by the complexity of the SVG and how much work it is for the browser to render all those pixels, especially on Apple devices that have super high-resolution screens. The great thing about SVG is that it's resolution-independent...but that's also the BAD thing about it. The device must fabricate all those pixels dynamically. Some of the toughest things to render in SVG are gradients, clipping paths, and strokes. You've got all of those going on. To be clear, this probably has nothing to do with GSAP. I'd guess that all of GSAP's work accounts for less than 2% of the CPU load. If you need better performance, you may need to switch to <canvas> or swap some of the more complex graphics out for raster (pixel) images. I wish I had a simple setting that'd suddenly cause everything to render silky-smooth on all devices.
  12. Glad you figured it out. Yeah, CustomEase is a perk for folks who set up a (free) GreenSock account. It helps us foster connection with our users. Hopefully it's clear that we value community around here - it's one of the things that sets GreenSock apart. Happy tweening!
  13. Welcome to the forums, @PIBC-QingYe. I didn't quite understand your question. Are you trying to understand how to control when each timeline plays inside of a master timeline? The position parameter is the key. See https://greensock.com/position-parameter You can have total control of exactly when things play. Overlap as much or as little as you want. If you still need help, please provide a reduced test case in codepen so we can see what's going on in context. If you're not sure how to do that, see Happy tweening!
  14. Great. Hang in there through the learning curve - you'll be glad you did. Trust me - it'll "click" at some point and you'll be like "oh, this makes a lot of sense now." Enjoy!
  15. Welcome to the forums, @mosk. And thanks for being a Club GreenSock member! There are actually a lot of ways to accomplish this. You don't need a loop at all. Here's one way to do it: https://codepen.io/GreenSock/pen/11be77c0a93fbec853c7692a96b19985?editors=0010 The pertinent code: var mySteps = 7, durationPerStep = 1, pixelsPerStep = 200, tl = new TimelineLite(); tl.to("#square", durationPerStep * mySteps, {x:pixelsPerStep*mySteps, ease:SteppedEase.config(mySteps)}) .to("#square", durationPerStep * mySteps, {y:pixelsPerStep*mySteps, ease:SteppedEase.config(mySteps)}, durationPerStep / 2); Does that help?
  16. GreenSock

    Salut (non technical)

    That's great, @st3f! I sure appreciate hearing things like this, and thanks for joining Club GreenSock! Let us know if you have any questions. We're happy to help. Enjoy!
  17. FYI, this is in GSAP 2.1.3 which is now released. 👍
  18. Hi @srapport. I'm not a TypeScript or React guy, so I'm probably the wrong person to help but I'm curious - do you just need a CustomEase TypeScript definitions file maybe? I suspect that the @types/gsap package doesn't include one.
  19. Aha! I see the problem. GSAP does a ton of work to manage conflicts and ensure that things run smoothly even if you interrupt things mid-tween. One of the things it does in the case of a className tween is to see if there's already one running on that element, and clear things properly (which likely involves editing/reverting inline styles). To work around some browser inconsistencies and ensure that things render properly, it records the element's cssText (all the inline styles) and then after it does its work of applying the new class and analyzing the differences in all the properties, it re-applies that cssText. In your case, that entails background-image too but you've actually got a URL that changes the image supplied randomly! You can get the exact same effect by removing TweenMax altogether and simply doing: //doesn't change anything, but the browser re-loads the background-image if you've got cache disabled: elem.style.cssText = elem.style.cssText; I'll add a line to CSSPlugin that only runs that code if the recorded value is different than the current one. Seems to resolve this edge case. You can preview the next version of GSAP (uncompressed) here with that change in place: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js Better?
  20. Also, for the record, I'd recommend avoiding className tweens because those require looking at literally every...single...CSS property to find anything that has changed between the old and new className, and then tweens each one. It's much better to just specify the properties you want to animate. If all you're doing is swapping classes, it's probably simpler to just use a CSS transition. Oh, and there is one case where an image's src must get updated internally, and that's for backgroundPosition because it has to measure the width/height of the native image so that it can accurately handle things like percentages. As far as I know, it's impossible to do otherwise. I found the original email notification about this thread and it contained a link to a valid codepen, so I peeked at that and it does indeed look like you've got a backgroundPosition in play there, and it's percentage-based. Perhaps that explains things.
  21. Hm, that codepen you provided was totally blank. I'd love to see a demo because I can't imagine how or why GSAP would force a reload of any images. Feel free to scour GSAP's source code and I think you'll see that it doesn't do anything like that (but please tell me if you find something - maybe I'm missing it). Any chance you could post a codepen that's not blank? I think there must be a misunderstanding somewhere.
  22. A few things... Sounds like an immediateRender thing. Try setting immediateRender:false on your from() tween. To learn more, see https://greensock.com/immediateRender I'd recommend being very careful about scaling things to such a large degree because it could cause rendering challenges with the browser (unrelated to GSAP). In your demo, you're scaling it to 14,500% which makes the bounding box HUUUUGE. The browser cares about how many pixels change on the screen, as dictated by the bounding box, so you're asking a LOT of the browser. Chrome is notorious for having issues with elements that are promoted to a new layer (to benefit from GPU acceleration). I noticed some artifacts until I set force3D:false which basically tells GSAP not to automatically layerize things for GPU acceleration. It's somewhat related to the whole "will-change" thing which I detail here: https://greensock.com/will-change Does that help?
  23. Ha. The colors are randomized, sorry. But with the updated forums software, I think they automatically make it look like poo if they use funky characters in their username
  24. It was more of an experimental feature, that's all. Sometimes we'll try some things out and see how they do in the public arena before officially committing to them or a specific API. The cascadeTo() thing doesn't seem terribly useful by a large portion of the audience, so it'll likely be dropped in 3.0 (and that's also why we never documented it). Sorry about any confusion there.
  25. Sorry about that, @ronnys - I never thought someone would go past 1000 seconds but I can add a setting in the next version of GSDevTools that allows you to specify a maxDuration in the vars object. I just updated the codepen-only version with that change if you'd like to test it: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/GSDevTools.min.js