Jump to content
GreenSock

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

Acccent last won the day on June 5 2018

Acccent had the most liked content!

Acccent

Moderators
  • Posts

    208
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Acccent

  1. I only changed the animation and didn't look at the rest of the code, as there's a lot of it. The problem must be coming from somewhere else! If you could make a more reduced test case that would make it easier for us to help you out :)

    • Like 3
  2. Hi!

     

    Well, if you open the inspector on the website you linked, you can get an idea of what they're doing. On each scroll/click, they're actually completely removing the current image (ie. getting rid of a node), and replacing it with a new one which contains the new image. That new image's opacity and scale animate, so that it fades in and either slightly shrinks or grows depending on the scroll direction.

     

    That's not necessarily the only way to do this though. You could have all the images except the first one invisible by default (with display: none), and then on scroll you make the current one invisible and use autoAlpha to animate the new one into view. Does that make sense?

    • Like 5
  3. I've never worked with Highcharts, Ceros or D3, but I know it's possible (if a but cumbersome) to create pie charts with pure CSS (

    See the Pen eNLaWj by Garnel (@Garnel) on CodePen

    for one example among many) and anything done with CSS can be easily animated with GSAP. Of course you could also just make one with SVG, which would simplify things even further.

     

    If you want the easiest solution though, you'd just make histograms :P

    • Like 3
  4. Hi jakub40,

     

    This looks like it's related to ScrollMagic, which this forum isn't dedicated to. You'd probably have more luck looking at ScrollMagic's official documentation or asking in its issues page on GitHub.

     

    However, from what I can tell, it looks like maybe you shouldn't be chaining .setTween methods immediately after creating the new scene? So you could try something like:

    var scene = new ScrollMagic.Scene({triggerElement: ".layer_grouop", duration: 550});
    
    scene.setTween(".layer_8", {top: "100px"})
         .setTween(".layer_7", {top: "100px"})
         ...

     

     

    • Like 2
  5. So, turns out I'd forgotten to swap out import 'gsap'; in one of the files, which explains why the size didn't change and everything worked immediately.

     

    Once I fixed that, I did have to make an explicit reference to CSSPlugin for everything to work (importing from /all or /TweenLite made no difference, except I had to manually import some eases from EasePack when I wasn't using /all).

     

    I gained 18 KiB (going from 800 to 782KiB minified, including all other assets), which I think isn't really worth the added maintenance and potential for invisible mistakes. (If you don't import CSSPlugin, there's no warning at all, but the tween just don't do anything – I'm not sure that there isn't something else silently failing somewhere else.)

    It makes sense that the gain is so small, I'm using TimelineMax so the only thing that isn't used is the added stuff from TweenMax. It's probably possible to fragment GSAP into more granular chunks, but that's a challenge for another day, haha.

     

    edit: maybe, when transitioning to 2.0, you should consider renaming TweenLite and TweenMax to just Tween, and TimelineLite/Max to just Timeline. The functionality would be defined by what you import anyway – I don't think there's a reason to have both names, is there? It can be a bit confusing when starting out with GSAP to decide whether to use Lite or Max versions, when, really, as long as you need the Max features once, you might as well just use it everywhere.

    • Like 1
  6. Hello everyone!

     

    I've finished* working on my personal website and thought I'd share it here, both because I think it's cool and also because feedback is always welcome and useful :)

    It's built with three.js but virtually all the animations are handled with GSAP. Feel free to poke around and ask me if you want to know how I approached things.

     

    https://robin-v.net

     

    *Obviously, it'll never be *truly* finished... I'm sure I'll start finding lots of stuff that needs fixing now that I've shared it, and regardless I'd like to integrate a Grav-powered blog in the future. But, you gotta show it at some point!

     

    Cheers ^_^

    • Like 7
  7. Well, just replacing all the import 'gsap'; with import { TweenLite } from 'gsap/all'; (and TimelineLite and TimelineMax where appropriate) worked immediately. CssPlugin was imported as expected without me needing to reference it explicitly, nor adding it to the sideEffects in the webpack config. That was a nice surprise.

     

    However the final size of the bundle is very slightly higher (1 Byte), so that's a bummer, haha. Even though I'm not technically importing all of TweenMax. shrug!

  8. This is what the docs currently say:

    Quote

    Clears any initialization data (like starting/ending values in tweens) which can be useful if, for example, you want to restart a tween without reverting to any previously recorded starting values. When you invalidate() an animation, it will be re-initialized the next time it renders and its vars object will be re-parsed. The timing of the animation (duration, startTime, delay) will not be affected.

     

    Another example would be if you have a TweenMax(mc, 1, {x:100, y:100}) that ran when mc.x and mc.y were initially at 0, but now mc.x and mc.y are 200 and you want them tween to 100 again, you could simply invalidate() the tween and restart() it. Without invalidating first, restarting it would cause the values jump back to 0 immediately (where they started when the tween originally began). When you invalidate a TimelineLite/TimelineMax, it automatically invalidates all of its children.

     

    I think it could use some more specific language, and the phrase "its vars object will be re-parsed" seems  especially confusing now!

     

    Here's a suggestion:

    Quote

    Clears any initialization data (like starting/ending positions of elements) which can be useful if, for example, you want to restart a tween without reverting to any previously recorded starting values. When you invalidate() an animation, it will be re-initialized the next time it renders and its vars object will be applied to the tweened elements, using their current state as the new starting point. The timing of the animation (duration, startTime, delay) will not be affected.

     

    The values passed in the vars object will remain the same. Something like TweenMax(mc, 1, {x:variable}) will always tween mc.x to the value that variable had when the tween was first created. Using invalidate() in this scenario allows you to apply that same initial value, but with new starting and ending points. The exception to this rule is function-based parameters, which are reevaluated whenever invalidate() is called.

     

    For example, if you have TweenMax(mc, 1, {x:100}) and mc.x is set to 0 initially, every time you run it mc.x will go from 0 to 100. Even if you manually change mc.x to 200, when you next run the tween mc.x will jump back to 0 and animate to 100. You can avoid that jump by using invalidate(), which will use the current state of mc to set a new starting value for the tween; in this case, mc.x will now animate from 200 to 100.

     

    When you invalidate a TimelineLite/TimelineMax, it automatically invalidates all of its children.

     

     

    ***

     

    Another question: does invalidate() have any effect on from() tweens? I can't see how it would?

  9. 5 minutes ago, determin1st said:

    Is there any reason why .invalidate() is not done automaticly when .play() happens?

     

    I assume it's for both for performance, and also because these are two distinct behaviours and both can be useful in some cases.

     

    Here's a follow-up question: assuming there's a choice between a percent-based timeline, that's responsive by default, and one that uses x and y but needs to be recreated every time, what's the better approach? I guess both performance-wise and when it comes to workflow? (This may be subjective!)

  10. This is super useful!

    So invalidate does basically 2 things:

    - re-record the start and end values of tweens based on the current position of elements (but without reevaluating the values passed when creating the tween)

    - HOWEVER, it somehow does re-evaluate the function-based parameters, which is useful to know.

     

    Does that mean that essentially, resize handlers (and other similar stuff) should basically recreate timelines entirely?

  11. ha, I unknowingly created a thread that is about a similar thing. 

     

    Hopefully we can get to a a point were we have a definitive resource on this and we don't have to reinvent the wheel every time!

  12. Hello everyone :)

     

    So this is a topic that comes back often, I guess both in the forums and in my head. Today's one of those times, and it would be nice if we could find a way to put it to rest together!

     

    I'm talking about how to properly use invalidate() and to make timelines that can adapt to things like a window resize or other events.

     

    Please have a look at the codepen. When you press play, the sphere moves along the line using 5 different techniques:

    • passing values to the x and y parameters
    • passing functions to x and y
    • passing values that are calculated with getBoundingClientRect() inside the timeline
    • tweening the transform property as a string (in order to use em units)
    • tweening the xPercent and yPercent parameters

    If you resize the window or use the up and down buttons, the square changes size (it's based on its font-size). Every time you press the play, the timeline is invalidated before playing again. It becomes apparent that the only technique that is affected by invalidate() is the 2nd one: the functions are re-evaluated at this point. xPercent and yPercent are unaffected but they do work as expected since they're percent-based (you don't even have to invalidate).

     

    Something like val = 2; tl.to(element, 1, {x: val}); will always behave the same way, even if you change val and then invalidate tl. I believe this is because val is a primitive, and so what's passed to x is the value itself, not a reference to the variable. Is this correct, or am I missing something?

     

    In other words, what's the optimal way to create and work with timelines to make sure they are responsive (without relying entirely on xPercent and yPercent, as that isn't always an option)?

     

    Ideally, I hope we can fully clear this up but for myself and others, and maybe have a pinned thread or a page in the docs that clarifies this, as it's a constant headache I think :)

     

    See the Pen OZgzgm?editors=0100 by Acccent (@Acccent) on CodePen

  13. @anotheruser, did you have a look at the demo in other browsers? It should look identical. There's no way to achieve absolute, perfect smoothness when scaling text, without converting it into an image first (and even then, I think you'd have a similar result to what I did – using scale and will-change basically does convert the text to an image before the transform, which is why it looks blurry if you scale it up).

     

    If you do see significantly different results in Chrome and Firefox, maybe make sure the issue isn't with the version of Chrome you have installed?

    • Like 3
×