PointC Posted March 17, 2020 Share Posted March 17, 2020 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 6 Link to comment Share on other sites More sharing options...
GreenSock Posted March 18, 2020 Share Posted March 18, 2020 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? 5 Link to comment Share on other sites More sharing options...
ZachSaucier Posted March 18, 2020 Share Posted March 18, 2020 @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? 2 Link to comment Share on other sites More sharing options...
Shrug ¯\_(ツ)_/¯ Posted March 18, 2020 Share Posted March 18, 2020 @PointC comes out of hiatus and makes a few posts, each pen is picked as Codepens of the day. 😜 Showing up like ... 2 2 Link to comment Share on other sites More sharing options...
OSUblake Posted March 18, 2020 Share Posted March 18, 2020 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. 4 Link to comment Share on other sites More sharing options...
PointC Posted March 18, 2020 Author Share Posted March 18, 2020 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? 2 Link to comment Share on other sites More sharing options...
PointC Posted March 18, 2020 Author Share Posted March 18, 2020 hmmm... maybe that 'throw to 0' thing is just with the embed here on the forum. Viewing it on CodePen seems okay to me. 2 Link to comment Share on other sites More sharing options...
PointC Posted March 18, 2020 Author Share Posted March 18, 2020 7 hours ago, Shrug ¯\_(ツ)_/¯ said: @PointC comes out of hiatus and makes a few posts, each pen is picked as Codepens of the day 1 Link to comment Share on other sites More sharing options...
GreenSock Posted March 19, 2020 Share Posted March 19, 2020 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 3 Link to comment Share on other sites More sharing options...
GreenSock Posted March 20, 2020 Share Posted March 20, 2020 This fix is in the latest release that we just pushed out officially (3.2.5). Enjoy! 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now