Server Varies GSAP Results?

[jdhadwin]

Same code, verified same (xy) coordinates being passed  to gsap.to(), good results on testing server, and very different animation on real-world server.  How is it possible?

Here's a video to check out the phenomenon:  

 

[GreenSock]

That's pretty weird indeed, @jdhadwin. It's pretty much impossible for us to troubleshoot without being able to reproduce that on our end - can you please provide a minimal demo like a CodePen or Stackblitz that illustrates the problem clearly? No need to include your actual code - just the most simple form to show the problem.

 

Just one tiny hunch that probably won't do anything, but try setting smoothOrigin: false on your tween. 

 

Once we see a minimal demo, I'm sure we'll be able to offer better advice. 

[jdhadwin]

Thanks.  As you predicted smoothOrigin:false changes nothing.

However, BIG CLUE... setting transformOrigin to anything DOES unify the two sources so that the animation ends at the same point.
Thoughts?

 

At this time I cannot reproduce the problem with code pen, but working on it, however, I did get it to land in the wrong spot with this pen...  just problem is, it also acts the same on my testing server as it does on codepen.  Other confusion here is that shouldn't the origin of the g element arrive at the destination without transformOrigin set to center center?

 

In the demo below, the set() and to() methods both send the orange circle to the same coordinates, HOWEVER, once the group is shrunk, it interprets the coordinates differently.  Click the blue dot to execute the set() method or the orange dot to do the to() method.  You'll get different results with the set() method based on whether the orange dot group is shrunk.

 

See the Pen bGJdaoV by jdhadwin (@jdhadwin) on CodePen

[jdhadwin]

@GreenSock In the HTML of the codepen above, the circle #billInput is at cx:0 and cy:0, that's the big orange circle, and it's placed inside the g element #subject.    The circle's center is at the origin of the g element.

 

It is my understanding that 

gsap.to(subject, {duration:1, scale:.05});

would by default transform around the center of the circle #billInput, because the center of the circle is the x:0 y:0 origin of the group being transformed.  In my video above, on the testing server, the gsap scale tween of the g #subject would scale around the center of the circle, yet on the live-server it scaled around the center of the g #subject bounding box.

 

That is why I found that adding transformOrigin: 'center center' unified the destination at which the tween landed.  Without transformOrigin, it arrived at different destinations based on whether it was served by the testing server or online.  Which is the correct behavior, default bBox center or default group origin at x:0 y:0?

 

[GreenSock]

39 minutes ago, jdhadwin said:

It is my understanding that 

gsap.to(subject, {duration:1, scale:.05});

would by default transform around the center of the circle #billInput, because the center of the circle is the x:0 y:0 origin of the group being transformed.

That's incorrect - the spec states that SVG elements by default use the top left as the transform-origin which is a bit confusing because normal HTML elements use their center as the default transform-origin. None of that is GSAP-dictated. So that certainly explains the issue you're talking about - just set the transformOrigin: "50% 50%" explicitly via GSAP and you should be golden. That resolves everything for you, right? 

 

I really can't speak to what's going on with your testing server; my guess is that the element isn't present in the DOM, thus there is no width/height which would kinda make it act as if the origin is in the center since there's no width/height. 

[jdhadwin]

@GreenSock the difference between the two servers is blowing my mind.

Nevertheless, it would solve my problem, except that I have other elements animating and scaling around the group, and they are changing sizes and locations, affecting the bBox size of the g.  So center won't cut it in my case.  I need to explicitly anchor to the original origin of the g.  Trying to think of a way without a zillion calculations onUpdate.

[jdhadwin]

12 minutes ago, jdhadwin said:

Nevertheless, it would solve my problem, except that I have other elements animating and scaling around the group, and they are changing sizes and locations, affecting the bBox size of the g.  So center won't cut it in my case.  I need to explicitly anchor to the original origin of the g.  Trying to think of a way without a zillion calculations onUpdate.

Well, it just occurred to me, that I could ensure that transformOrigin: 'center center' stayed at the x:0 y:0 of my g element if I simply put a giant invisible circle at x:0 y:0.  Then the inner elements can be animated like crazy and yet the bBox would remain the same size.  Technically the problem is solved, as now both servers render the same outcome, however, mind is still boggled on the difference in the first place.

[GreenSock]

I'm not really sure what you mean (a very clear minimal demo in CodePen that shows that scenario would go a LOOOONG way toward getting you a solid answer), but what about using the svgOrigin feature? That lets you explicitly set an origin relative to the overall SVG.

 

See the Pen waKrNj by GreenSock (@GreenSock) on CodePen

 

https://gsap.com/resources/svg

[GreenSock]

2 minutes ago, jdhadwin said:

mind is still boggled on the difference in the first place.

Have you tested my theory? Check the getBBox() of the element on both and see if they match (testing and live servers). Do so at the very start (not when you click). 

[jdhadwin]

22 minutes ago, GreenSock said:

Have you tested my theory? Check the getBBox() of the element on both and see if they match (testing and live servers). Do so at the very start (not when you click). 

I only tested it on update... and it was the same there... but I haven't checked it before.  I will check