[An instant flare at the bottom, a black strip on top!]

Hi makis,

 

Thanks for the codepen. Could you post a screenshot of what you're seeing? I'm not sure what I have is normal or not. I don't see any flare

[Splittext and Denavagari]

Hi all,

 

I thought I'd post this recent find in here, as it might be relevant

 

https://github.com/orling/grapheme-splitter

[Create fast click animation]

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

[Create fast click animation]

Here's a fork of your pen, I marked the changes in the CSS and JS with "CHANGES HERE". The scale is always animating up, but it should be enough to get you started.

 

See the Pen pKbvOG?editors=0010 by Acccent (@Acccent) on CodePen

 

[Create fast click animation]

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?

[Charts / Data Visualization]

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

[Does anyone use Greensock in Desktop App? (Haxe, React, Flex...)?]

I'm currently building an app with Electron as well, and have run into no issues so far

[Many setTween]

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"})
     ...

 

 

[Truly responsive Animations]

Really interesting that modifiers is another way to avoid "caching" values!

[GSAP is undefined if a dependency uses GSAP too.]

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.

[New website! GSAP + three.js]

haha, I hope my website gets better approval rates than Macron in france ?

[New website! GSAP + three.js]

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

[GSAP is undefined if a dependency uses GSAP too.]

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!

[GSAP is undefined if a dependency uses GSAP too.]

Out of curiosity, if I'm using Webpack now, is it worthwhile to use this too? (I understand I'd need to explicitly reference the plugins I use, but I think there's only CssPlugin at the moment). I currently just do "import 'gsap';".

[Change duration for the last two objects using staggerTo]

Isn't it potentially risky to pop the last element of the children array? What if it's needed later?

// Maybe this
children[children.length - 1].duration(1.8);
children[children.length - 2].duration(1.8);

// or
children.slice(-2).forEach(t => { t.duration(1.8); });

 

[A final clarification about invalidate() and responsive timelines]

I use .to({}, 1, {}) somewhat often. I wouldn't want the tween to just get ignored when I use it specifically to measure time, and I'd also want to be able to tell if it's active or not

[A final clarification about invalidate() and responsive timelines]

Oh, of course, haha.

 

Later on I'll post a draft for a full guide on when to use xPercent, invalidate(), function-based parameters or when to recreate timelines entirely, depending on the situation. Just need to find the time hehe

[A final clarification about invalidate() and responsive timelines]

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?

[A final clarification about invalidate() and responsive timelines]

It does, in the sense that I tend to build stuff that's already on the "too expensive for the CPU" side of things, so I guess now the strategy is to try to recreate the timelines when they're not needed so it can happen in the background and they're ready when they actually do have to play

[A final clarification about invalidate() and responsive timelines]

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!)

[A final clarification about invalidate() and responsive timelines]

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?

[Truly responsive Animations]

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!

[A final clarification about invalidate() and responsive timelines]

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

[Scale with text shaking the div]

@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?

[RoundProps with optional decimal count?]

I think this is super good, personally. Best implementation of this I can think of – to the point where if it was up to me and I didn't need the library to keep working for 70 bazillion websites, I'd deprecate the current string grammar