Jump to content
Search Community

Draggable endX differences GSAP 2/3

PointC test
Moderator Tag

Recommended Posts

I've been updating my slider demos to GSAP 3 and noticed a difference in endX and a snap array. In GSAP 2 the endX would always be accurate, but in GSAP 3 I'm getting numbers that aren't in the array. At first I thought it was a rounding error, but depending on how you throw the target, you can get some wildly different numbers. Am I doing something wrong here or has something changed when I was on hiatus?


Here are comparisons of 2 and 3.


See the Pen ExjRaJV by PointC (@PointC) on CodePen



See the Pen mdJKJVx by PointC (@PointC) on CodePen

  • Like 6
Link to comment
Share on other sites

Great catch, @PointC. That required a minor tweak to each of the following: core GSAP, Draggable, and InertiaPlugin. Basically it had to do with the fact that the new InertiaPlugin can automatically set the duration of the tween and there was a scenario where the order of things running on the first render (in this case Draggable pushing the tween to the very end to figure out the endX/endY) would figure out the progress value based on the OLD duration. Anyway, here's an updated fork of your codepen that seems to work well for me: 

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



  • Like 5
Link to comment
Share on other sites

12 hours ago, GreenSock said:

That required a minor tweak to each of the following: core GSAP, Draggable, and InertiaPlugin

Are there any cash and prizes for breaking three things at that same time? ?


Yeah that seems a lot better, but as @ZachSaucier mentioned, it's tough to throw the target to 0. Is that something that needs to be addressed?

  • Haha 2
Link to comment
Share on other sites

15 hours ago, ZachSaucier said:

@GreenSock In your demo, it seems pretty tough to throw the box to the start (0) position. All of the other snap positions snap to with more ease. Is that a bug?

Interesting. Should be fixed now. Here's what I discovered...


There was a "bounds" declared which imposes its own max/min (in addition to the array of snapping values). When that bounding element is positioned such that its bounds are on a half-pixel (a 100px-wide element that's centered in a 101px-wide parent, for example), the rounding of that minimum goes UP 0.5 pixels. Math.round(0.5) is 1. So when that codepen was embedded in this page, it was positioned in a way that'd end up in that scenario, thus when you tried to throw the element all the way to the left and the array said "the closest value is 0" but the bounds said "no way, buddy, the minimum is 1 so you're not allowed to go to 0!" That was the problem. 


So to fix it, I subtract 0.5 pixels before rounding the minimum :)

  • Like 3
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.
  • Create New...