Jump to content
GreenSock

elegantseagulls last won the day on October 20 2018

elegantseagulls had the most liked content!

elegantseagulls

ShockinglyGreen
  • Posts

    98
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by elegantseagulls

  1. @kevmon

     

    I'm thinking you'll either need to take the approach I took with eases, or have the Sun be contained in the SVG.

     

    Another solution to provide more true-to-path accuracy would be to use the CustomEase plugin. This uses your SunPath to create the ease, and I'm using relative units to ensure it traverses the viewport:

     

    See the Pen aMxPNo by ryan_labar (@ryan_labar) on CodePen

     

     

    That said, I haven't had my morning coffee, so someone may have a better solution using your current setup.

     

     

    • Like 4
  2. Have you tried breaking the animation down into simple parts to see where the issue is stemming from? You're getting a bunch of console warnings with the floating hearts. I'd try disabling that to see if the issue is with your drawSVG or your hearts. My hunch is that its due to animating `attr: { x: x, y: y },` instead of using a transform `x:x` (which can be passed to the GPU). If you turn chrome's paint flashing borders on there's a lot of random extra paints on these hearts..

    • Like 2
  3. I see a few things that may help.

     

    It looks like you're setting a new current slide on the click event, so when you click rapidly, the animation is resetting to the new current slide. To help this, you may want to set the current slide index via `onComplete`.

     

    There's also a jump on your next slide animations; they are less noticeable just due to how the 'left' property works. To further eliminate these 'jumps' in both directions you'll want to set the fromTo values based on the slide's current (when arrow is clicked) position.

     

    Also, from a performance standpoint, consider use 'x' (transform) over 'left', this will allow for smoother animations. This article does a great job explaining the why: https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108

     

    Hope this helps.

     

    • Like 3
  4. @noineter

     

    Quote

    I am really interested in greenSock but there is just not enough information about it online in my honest opinion.

     

    If you're looking for resources on GSAP, there's a ton, and the docs are very detailed, too:

    https://greensock.com/docs

     

    https://greensock.com/learning

     

    https://ihatetomatoes.net/get-greensock-101/

     

    https://frontendmasters.com/courses/svg-animation/

     

    Or just spend a few hours on this forum. There's a wealth of knowledge and passion for helping here that I've not seen for any other web development tool.

     

     

    • Like 5
  5. Hi @MikeWillis,

     

    My suggestion would be to break the animation down into parts to find out what part of the code is causing it to be choppy. I wasn't able to easily read enough of what's happening in your code, to give a direct suggestion. I think you may be better of using a play() / reverse() on toggle the show hide too, for simplicity sake (see this nav toggle I built a while back

    See the Pen Vezxxy?editors=1010 by ryan_labar (@ryan_labar) on CodePen

    ).

     

     

     

    • Like 4
  6. @wcomp - if you're already making 40 paths, you'd be better off building the sprite than morphing that many. You can do the sprite in SVG too, since you are using Inkscape already. If it were me, I'd use the viewBox to hide the off-screen sprites. Just remember, for smooth animations, you'll want to be close to 60 fps (down to 30 would be acceptable too). So you'd end up with an SVG looking like:

     

     

    <svg viewBox="0 0 100 100">
    	<g class="transformMe">
    		<path />
      		<path />
      		<path />
      		<!-- ...etc. Each, in this instance would be 100 units appart -->
    	</g>
    </svg>

     

    and your GSAP looking like:
     

    TweenMax.to('.transformMe', .5, { 
      x: -2900, // if you had 30 sprites (100 * (30 - 1))
      ease:  SteppedEase.config(29) // 29 steps cause first one is already in view
    })

     

    • Like 3
  7. You might be able to segment the tail of your arrow up into several paths that each autoRotate on their own to achieve something similar. It'll probably take a lot of trial and error with some other properties to get where you'd need, though, and may be tough to get the curve as smooth and your illustrated sample. 

    Think on these lines:

    https://codepen.io/lukasoe/pen/YNEoQR

    https://codepen.io/pmk/pen/YPdJax

     

    Otherwise, you could do several morphs, or a sprite map as mentioned above. Here's a sample of a sprite animation that I created just using GSAP's stepped ease.

    See the Pen XBroJG by elegantseagulls (@elegantseagulls) on CodePen

     

    • Like 4
  8. Hi @BBaysinger. I'm with @GreenSock in that a simplified Pen may shed some clarity on what you are looking to achieve.

    That said, reading between the lines, the FLIP principle that @OSUblake, recently mentioned seems like it may be what you're looking for: 

    https://aerotwist.com/blog/flip-your-animations/

     

     

    See his CodePen example here:

     

    See the Pen NeBpJm by osublake (@osublake) on CodePen

     

    • Like 2
  9. Hey GSAPers,

     

    Was thinking about this last night, and didn't see it in the Docs, what's the difference between onUpdate and TweenLite.ticker.addEventListener(); speed of fires, etc? If both are equally available which is more performant?

     

    Thanks,

    Ryan

×