Jump to content
GreenSock

phidur

Members
  • Posts

    7
  • Joined

  • Last visited

phidur's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. Great! Thanks for the response. I think this was the key piece that I was missing "y:{end:drawerY}". Works like a charm
  2. Hi - brand new Shockingly Green member here and I'm playing around with the throwProps plugin. Really, really liking it so far, the work you guys do is really impressive. I'm having some trouble with a few customizations. In particular, I'd like to configure my Draggable (a "drawer") with throwProps: true so that the default ease is Expo.easeOut. I've toyed around with different ways to make this happen, but I'm not quite getting it. It's almost certainly due to my unfamiliarity with the plugin, so I thought I'd ask the pros. Thanks!
  3. @GreenSock, @PointC - thanks for the insight guys! I reckon I've been "trained" by previous versions of GSAP that .set() calls at the start of a timeline should fire immediately, but programmatically, it does seem more consistent after the change. My new understanding - any operations involving rendering are executed at the next tick, but .pause() sets the internal timeline flag immediately. So in the scenario of timeline.set().pause(), by the time the next tick has rolled around, the timeline is already paused and nothing renders (this all assuming that immediateRender is not true). It'll take a few minors adjustments in my code, but nothing too bad. Appreciate the help, cheers!
  4. Hi @PointC, thanks for the response, it has certainly helped me isolate my issue. The discrepancy in behavior that I'm experiencing between GSAP 2.0.2 and 2.1.2 seems to be in relation to placing a timeline.pause() call immediately after timeline.set() - e.g. timeline.set("#box1", {x: 300}).pause() In GSAP 2.0.2, the .set() executes before the timeline is paused. In 2.1.2 this does not seem to be the cause. I forked your codepen to show this. When I change the GSAP version number, I see different results. Are you seeing the same thing? Is this expected? Thanks GSAP 2.0.2: GSAP 2.1.2:
  5. In the documentation for the GSAP 2.1 update it says that immediateRender defaults to false for all timeline.set() function calls. So if I need to call timeline.set() on a newly instantiated (zero-duration, unpaused) timeline before adding any tweens to that timeline, are those timeline.set() function calls ever executed if no tweens are added? Are they executed before any newly added tweens? Because the timeline is unpaused, I would expect those timeline.set() calls to execute regardless of what follows and before any subsequently added tweens begin animation. However, this is not what I am experiencing in either case. I can achieve the desired result with immediateRender: true, but this doesn't seem like expected behavior to me. I know this is one of the issues you guys have been wrestling with and some of the immediateRender changes were rolled back in 2.1.2, so I just wanted to make sure I wasn't missing something/this isn't a bug. Thanks and keep up the amazing work! Edit: In case it was unclear, I am using GSAP 2.1.2
  6. Hi @Diaco, thanks for the reply! That does the trick and was there in the documentation all along - cheers!
  7. Hi all, I've been using GSAP for a while now and frequently browse the forums for advice/tips. The GSAP team makes amazing products and I couldn't be happier with them. Thanks for all the great work! Recently I've been having a lot of fun with the Draggable utility, but just ran in to a couple of problems today within the Chrome browser on Android. I would like to start dragging my Draggable when a separate "anchor" element outside of the Draggable is dragged (touchmove'd) left or right. Kind of like a "hotspot" to start the dragging action. For reasons unknown to me, the following codepen does not work properly. However, if I change all "touchmove" listeners to "mousedown" listeners, the codepen behaves as expected when using a mouse. Full disclosure: it's actually a different issue I was trying to resolve regarding the way Chrome handles touch events vs pointer events when I ran into this little stumbling block. I'm sure that my issue here is something small/silly. Thanks!
×