Jump to content

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

Unexpected Path Result for Tween

Go to solution Solved by jh-thank-you,

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

GreenSock Community,


Thanks for taking the time to read this post, also thanks in advance for any help you may provide.


I have a modal that scales up a selected thumbnail into a scrollable slide container.

Please note the CodePen only has the "Advil" link set to call in Ajax content (HTML and JS) from another CodePen 

See the Pen rjqNaY by jh-thank-you (@jh-thank-you) on CodePen


I have two problems with the Tween Path:

  1. The starting position does not seem to be the correct coordinates, despite my using that part of the code exactly as what the original example is using (see getPosition function and the rect var).
  2. I'm having an issue with the path animating on an arc (curved path). I think this is due to my using Top 50% and Left 50% along with transform/translate to center the image within the browser's window)... I seem to remember reading somewhere in the GSAP forums that this is due to the rendering order... that Top/Left/Right/Bottom are calculated last... if this is true, do you have any suggestions on how to center the image within the browser's window and solve this render order issue?


The modal is based on a CodePen by one of the GreenSock Moderators (thanks again Blake for all the help

See the Pen 7f3b39b23861664c3ecc399e23112b2a?editors=1111 by osublake (@osublake) on CodePen

). Also,the slide container is based on another GreenSock Community Member's example (thanks Chrysto 

See the Pen kDvmC by bassta (@bassta) on CodePen



I have made the main part of the tween set to 6 seconds (slowing it down) so you can see how the starting position is off and how the top and left calculations happen at the end.


Thanks again for any help/guidance. 

See the Pen pROXPW by jh-thank-you (@jh-thank-you) on CodePen

Link to comment
Share on other sites



Thank you for the help, I really appreciate it.


Here is a fork without any scaling applied to the clone:


See the Pen BpqOBW by jh-thank-you (@jh-thank-you) on CodePen

  1. Note: I figured out one part of the issue, the CSS for padding on the clone, that is in the style sheet, is being applied too early in the tween... I'm solving this by adding  a class name onComplete. This takes care of the clone being made smaller before scaling up.
  2. I added a red boarder to the clone, you can see the start position is set correctly (just like your

    See the Pen 7f3b39b23861664c3ecc399e23112b2a by osublake (@osublake) on CodePen




See the Pen KaGGEV by jh-thank-you (@jh-thank-you) on CodePen


  1. In this pen I have the clone scaling, hopefully without the background (and slowing it down / 3 sec duration) you can see how the clone moves left then back to the the center instead of directly towards the center.
  2. I believe this is due to the rendering/calculation order... I have been looking for an older Forum thread I read on this... someone else was having a similar issue. I think it was talking about Height & Width calculations vs Scale / Transform Translate methods rendering orders and how that can throw things off.

Thanks again for the help, also thanks for the likes on the other post, you and Dipscom have been so helpful... Do you guys work out of the same office... can I order in a lunch for you guys? I would like to do something a little extra for both of you... Both of you have gone above an beyond.

  • Like 1
Link to comment
Share on other sites

I'll haven't had a chance to look at this yet, but I will. My first guess would be the transformOrigin is throwing it off. Center is default. Maybe try setting it to left top.

transformOrigin: "left top"
Link to comment
Share on other sites

Thanks Blake,


Tried it but no go... if I don't use width and height to change the size, using scale instead, it seems to get rid of the issue. That said, if I use this approach I can't use 100vw as a target end size as CSS scale does not take that kind of unit measure... have to figure out another way.


Will update when I make some progress. 


Thanks again, enjoy the rest of your weekend.


P.S. Let me know a good day to order in a lunch for you and Dipscom (pick one of your favorite delivery places... let me know know what you want and a good delivery time).

Link to comment
Share on other sites

Hey Jim,


Firstly, me and Blake are rather far from each other physically. I'm sure he'll agree with me when saying that you should not worry about buying us anything. Pass the kindness forward, that's what matters. Being nice ;)


I have had a little stab at your issue. To be honest, I am not quite too sure what you are after. My guess is that you want the modal to scale into place, is that right?


I know you have tried to give us a limited version of it but it still is quite full on. If you could simplify this a bit more, it would help immensely. All those AJAX calls, the many things being loaded, the extra HTML that is not relevant, it all makes it hard for us because it is noise, it takes time to go over it figure out what is what and what is doing what.


All that would be needed here is a single button loading the modal and the simplest possible content in the modal. The rest could be anything later on. But for now, it's all about having the smallest possible amount of code that gets the job done.


I'm hacking away your sample pen, removing bits but I don't have too much time to spend on this at the moment. Already I think something is quite wrong as in your logs I see the same log with the same values being triggered three time after a single click.


See the Pen BpbYKp?editors=0010 by dipscom (@dipscom) on CodePen

Link to comment
Share on other sites

Here is the latest link for the Modal


See the Pen GrePeR by jh-thank-you (@jh-thank-you) on CodePen


This sorts the clone start position by removing the CSS padding at the start of the tween and adding a new class (clonePadding) onComplete.

  • For any other newbies, like me, this CodePen is now using dynamic links to bring in the appropriate images: I figured out how to make a dynamic link to bring in the appropriate image based on a URL link generated from the selected element's ID... this helps by making one set of functions that can now be used on the entire page's thumbnails to load the appropriate set of images into the modal's first slide (this is how the cross-fades/image stage is achieved).


As for the arched tween path, I am still using "100%" or "100vw" for the "to" target size. If I use the GSAP "scale" property the tween path is a straight line but I'm having positioning issues with the CSS (I'm still trying to sort what is the source of the problem). The CodePen Link below uses the "scale" approach with a formula for the target size, but I have not fully sorted out all the issues with the final, centered, position (trying to sort the max scale amount padding etc.):


See the Pen mRooRq by jh-thank-you (@jh-thank-you) on CodePen

Link to comment
Share on other sites



Thanks for the help.


While you were posting I was sorting out the other couple of CodePens that I just posted above.


I will cut them down and post back.


I will definitely pass the kindness forward... on the coding front my abilities are limited... but I have been looking at the forum questions every so often to see if there is something I can help with. On a pass it forward line of thought, for the last ten years I have been running a nonprofit that teaches martial arts, for free, to the kids and families in the community. H.E.A.R.T. Martial Arts is run out of Newark, NJ. If you are ever in the North Jersey area reach out, it would be great to meet and thank you in person. 


Thanks again.


P.S. My next web project will be for H.E.A.R.T. ... the site is an old, but free, google geosite.

Link to comment
Share on other sites

The simplified-ish seem to move ok to me. I can see the jerk in the more complex example, though.


I think I get what you are after, I see it behaves funky when scaling the window as the animation is happening. 


I still am struggling to read all of your code, there's still plenty there. Right now I don't have much free time so, keep trying and we'll help as much as we can. If some spare time appears, I'll have a stab at recreating something based on what I understand you are trying to achieve.


As for passing the kindness forward. There you go, you're already doing some. The world just need us all to be nice.


And code-wise. Trying to answer other questions has been the best thing I ever done to improve my own skills. You'd be surprised by how little I actually know. ;)

  • Like 1
Link to comment
Share on other sites



Thanks for the follow up. Sorry for the delayed response, its been a busy day, I had to switch gears to a client project. I will be sure to post an updated CodePen in a few days. 


Thanks for the kind words, have a great day/evening.


All the best.


PS I wanted to add I can't agree with you more about "The world just need us all to be nice."

Link to comment
Share on other sites

 Dipscom, Blake, GSAP Community,


Here are two simplified versions of the modal, they are a fork of Blake's Responsive Grid CodePen (no ajax calls or extra CSS etc.).


Each CodePen has it where if you click on any of the divs in the grid they will scale up and to the center of the browser's window. Each div will also scale back down when you click on it (or the background overlay) a second time.


This version uses the Height and Width properties to calculate the div size based on a percentage of the browser's window width:

See the Pen wgVLgW by jh-thank-you (@jh-thank-you) on CodePen

  • Note that this version follows a curved path (the issue I am looking to solve) as the div scales to center. Here is a animated gif, I have added a start and endpoint, red outline boxes, so you can see how the div moves right then back left towards the center as it scales up (as if transform origin is top, left). I tried Blake's suggestion of changing the transformOrigin but it did not work:
  • using-height-and-width-to-scale.gif 


This alternate version uses GSAP's Scale property to to calculate the div size based on a percentage of the browser's window width:

See the Pen GrVbWJ by jh-thank-you (@jh-thank-you) on CodePen


  • Here is a animated gif, showing the GSAP scale property. It also has the start and endpoint, red outline boxes. Notice how the scale (transform origin) method is applied from the center of the div. This results in a straight line path vs. a curved (hooked - for the lack of a better term) path:
  • using-gsap-scale-to-scale.gif


I believe there is a forum article that discusses this issue but I have been unable to find it again.


For what it's worth I hope this helps someone else out. 


All the best.

Link to comment
Share on other sites

I noticed that scaling is choppy in Chrome now, but you can smooth it out by out adding will-change to your css.

will-change: transform;

I hope that's not a long-term solution, but for now it works.


For the curve... I'm thinking that might require some extra work. If I remember correctly, the values used are all based on the center of something, but they should be on the where the top-left corner is going to be. So you might need to make adjustments for that. I'll try to make a simple demo using width and height.

  • Like 1
Link to comment
Share on other sites

Is this what you were trying to get it to do? I'm not taking into account the scroll position, but it's not following a curved path.

See the Pen MJNNLg?editors=1010 by osublake (@osublake) on CodePen

  • Like 2
Link to comment
Share on other sites

Hello jh-thank-you


If you didnt want to add will-change:transform on your .tile.clone css rule to make it more smooth and less jank.


You can instead add the following properties to your tween that use scale.


The above will tell GSAP to use matrix3d() instead of just using matrix() for the transform, which is what you currently have now.


You also might have to add some other CSS properties like backface-visiibility, transform-style, and perspective to help with some of the jank (lost frames) that are seen in Chrome.


Or you could add force3d:true to tell GSAP you want to use hardware acceleration. force3d default is "auto"


Another thing i noticed is, If it was me, I would remove the top:0 and left:0 CSS properties out of your tween on Line 125 and 126, since you already have top and left at 0 (zero) in your style-sheet for the .tile CSS rule. So there is no point to have those 2 properties on your tween. ;)



CSSPlugin Docs: https://greensock.com/docs/#/HTML5/GSAP/Plugins/CSSPlugin/



  • Like 3
Link to comment
Share on other sites

Blake and Jonathan,


Thank you for taking the time to respond. I did notice the jank... just didn't know what to do to get rid of it... I was just happy that I got the tween path to be straight.


I will definitely add these tips to my notes.


So what is considered the best practice way of solving this... or is it they are all acceptable, just be consistent throughout project? Does one approach have better performance vs another? 


I noticed in Blake's CodePen he is using parseFloat(); I found this in the forum about decimal percentages with zeros at the end of the string causing animation issues (hope this helps another newbie out):


Link to comment
Share on other sites

  • Solution

GSAP Team,


I have forked Blake's CodePen and added in the necessary calculations (taking scroll amount into consideration) for the final centering position.


Here is the CodePen Link: 

See the Pen QpLJGK?editors=1111 by jh-thank-you (@jh-thank-you) on CodePen


This seems to be smooth (no jank) as it does not use scale, it uses the Height and Width properties.


Thanks again Blake for pointing me in the right direction.



All the best,

  • Like 2
Link to comment
Share on other sites



If I am understanding things correctly:


The Height and Width are calculated from the top left corner and the origin position is set/calculated from the top left corner to start with in my original approach. Then by adding the xPercent -50% and yPercent -50% to achieve the center position I am changing the origin position throughout the tween which makes the path appear curved/hooked.


Your method stays with the top left as the origin point for the entire tween which results in the straight tween path. This top left point is determined by your calculation of the final size of the div in relation to the window size.

var x = centerX - rect.left - cloneW / 2;
var y = centerY - rect.top  - cloneH / 2;

Is that correct interpretation?


Thanks again.

Link to comment
Share on other sites

Yep. When you first started out, I suggested using the center for simplicity because you said were new to web development. But in general, it's easier to position stuff using the top-left corner, especially if width and height are involved as there is no transform origin.


For your previous question about the difference between what Jonathan suggested and the will-change, I don't think there is much of one. They pretty much do the same thing. I guess it depends on if you want to set that optimization in your css or a tween.


And about the parseFloat, I think that issue you linked to has been fixed. I only did that because the cloneVw/cloneVh values are strings with "px" on the end, and I needed to them to be numbers for the x and y calculations.

  • Like 3
Link to comment
Share on other sites

The reason I suggested what I did instead of using the will-change property. Is because the way Chrome is now treating the will-change property. Before Chrome version 51, will-change behaved like the spec intended. But now it causes very weird rendering or unintended intermittent poor performance lag in Chrome. Anything that I had that used will-change before Chrome 51 stopped working, almost like having the opposite effect. will-change is supposed to let the browser know the element will be pushed onto its own rendering layer. Like preheating the oven. Basically saving you from using:

transform: translate (0);

on the element CSS rule, to force hardware acceleration (GPU).

You can choose to do either or. Me personally prefer to allow GSAP to create the matrix3d() instead of hoping the browser will report the will-change property correctly in Chrome.

GreenSock's Jack also made a great article on this subject


And a link to the spec for the CSS will-change property:



  • Like 5
Link to comment
Share on other sites

Very confusing either way! I started using it because it fixed something I was working on. I didn't even think about trying to use force3D.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.