MotionPath start position not correct

[SamStAubyn]

I'm trying to get the image in the codepen to track with the line animation.

 

For some reason the start position of the image element is in the top left of it's parent container, I assume I'm missing a trick here to get it to start at the beginning of the svg path, as once you scroll it then aligns.

See the Pen VwNeYay by SamStAubyn94 (@SamStAubyn94) on CodePen

[GreenSock]

Yeah, that's because the position is affected only after the playhead isn't at 0. So for example, if you reverse the tween and the playhead goes all the way back to the very beginning and beyond, the element would go back to the original position (before the motionPath tween affected it). 

 

You can easily work around that like this: 

See the Pen ZEZQQpQ?editors=0010 by GreenSock (@GreenSock) on CodePen

 

Just use an onRefresh to force the playhead  to be slightly past the very start if it's at 0. And I set invalidateOnRefresh so that the path gets re-calculated since resizing the window would make the SVG change size.

 

Is that better? 

[SamStAubyn]

Yeah this works perfectly thanks! 

 

Question though, I would have thought the align arg would inherintly align the element to the start position of the path it would be tracking, is this something that will be included in future updates or is it left open so that the tracking element can be tweened prior without any interuption?

[mvaneijgen]

Nope, this is left open intentionally. This way you can have a path that is off screen and is not visible at all, also multiple elements could have the same path, but be aligned to their own parents. 

 

Personally I've always used a path that that is also used as the alignment, but that is the beauty of GSAP, you can build what ever you like and because some smart people have thought of all possible solutions you ever want, you are never locked in to how the tool wants you to work.

 

Hope it helps and happy tweening! 

[GreenSock]

Yeah, I wouldn't consider this a bug. Imagine you set up two different tweens that animate the same element on different paths (sequenced). If we implemented the behavior you described, the element would start on the 2nd path rather than the first, and immediately jump to the first path when that animation begins. And again, if you rewind the tween(s), it may not end up where you'd expect. But it's easy to accomplish the effect you're after, as I described. I think in a future release, I'll just have it look for the immediateRender: true on the tween and if that's found, it'll force that initial render.