Draggable endX differences GSAP 2/3

[PointC]

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.

[GreenSock]

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.

 

Better? 

[ZachSaucier]

@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?

[Shrug ¯\_(ツ)_/¯]

@PointC comes out of hiatus and makes a few posts, each pen is picked as Codepens of the day. ?

 

Showing up like ...

 

[OSUblake]

2 hours ago, Shrug ¯\_(ツ)_/¯ said:

@PointC comes out of hiatus and makes a few posts, each pen is picked as Codepens of the day. ?

 

He has a fan that works at CodePen. They hand pick what shows up on the front page.

[PointC]

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?

[PointC]

hmmm... maybe that 'throw to 0' thing is just with the embed here on the forum. Viewing it on CodePen seems okay to me.

[PointC]

7 hours ago, Shrug ¯\_(ツ)_/¯ said:

@PointC comes out of hiatus and makes a few posts, each pen is picked as Codepens of the day

[GreenSock]

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

[GreenSock]

This fix is in the latest release that we just pushed out officially (3.2.5). Enjoy!