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

Everything posted by Acccent

  1. 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
  2. Hi all, I thought I'd post this recent find in here, as it might be relevant https://github.com/orling/grapheme-splitter
  3. 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
  4. 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.
  5. 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?
  6. 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 here 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
  7. I'm currently building an app with Electron as well, and have run into no issues so far
  8. Acccent

    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"}) ...
  9. Really interesting that modifiers is another way to avoid "caching" values!
  10. 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.
  11. haha, I hope my website gets better approval rates than Macron in france ?
  12. 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
  13. 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!
  14. 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';".
  15. 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); });
  16. 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
  17. 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
  18. This is what the docs currently say: 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: *** Another question: does invalidate() have any effect on from() tweens? I can't see how it would?
  19. 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
  20. 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!)
  21. 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?
  22. 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!
  23. 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
  24. @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?
  25. 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
×