Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by unvs

  1. A little update on this:


    - I've managed to fix the operations with arrows -- it loops as it should finally :) 

    - I've *ALMOST* figured out the dragging/snapping. There is a bug I'm not sure on how to solve. If you drag from 1 to 6 (backwards), the threshold for snapping is not the same as the other slides. If you only move a couple pixels it still will snap to 6. It is wrong when moving the other way as well -- to make it snap to 1 when sliding from 6, you have to drag all the way to pass the 0 threshold.


    Does anyone have any ideas on how to solve that?

    See the Pen ExyRqgZ by unvs (@unvs) on CodePen

    • Like 1
  2. Hah, yes, I'm sorry - there are 2 things I'm unclear on how to solve in this codepen:

    See the Pen ExyRqgZ by unvs (@unvs) on CodePen


    1. I have an array of snap offsets which won't work on the modified slides. If I click and drag towards the left (to go to 2, 3, 4 etc), it snaps in place until 6, but then it stops (since it doesn't have any more values in the snap offset array, I guess?). I'd like to have it snap to the next 1 and 2 and 3 and so on. Can this be wrapped somehow?


    2. Clicking the left and right arrows work fine, but if you click the right arrow several times (until you are well into "loop 2"), and then drag it afterwards, it rolls back and snaps to the last known offset. I suspect this is connected with problem #1?

  3. Thanks for taking a look, I really appreciate it!


    The examples I found uses absolute positioning on the slides, and a fixed height on the wrapper. I was hoping to avoid that for easier styling, but I forked one of the examples and tried tweaking it to my needs:


    See the Pen ExyRqgZ by unvs (@unvs) on CodePen


    I'm a little unsure of how to operate the arrow buttons though :D 


    Now the backwards arrow goes forward and vice versa. Also it stops working when it arrives at the wrapping point. Not quite sure how to tackle that?

  4. I have a draggable slider/"panner" that is constructed a little differently due to some demands:


    - It has to work with percentage widths for the slides / flexbox

    - It has to work with differing slide widths


    This has worked all right in my solution, but now I'm trying to "loop" the slider and all examples I can find are using a draggable connected to a tween's progress and I'm not able to see how I can make this work in my situation.


    Any pointers here? I'd suspect I'd have to do some dom manipulation by moving the first slide to the end etc but I'm not really sure where to start.


    Any and all advice appreciated!

    See the Pen abZGroa by unvs (@unvs) on CodePen

  5. First of all, thanks for this, it does what I was looking for!


    I just have one question: Is it possible to make it just a little less "sensitive"? So that it will stop after the first section and require a new input to move to the next?


    When I scroll with my touchpad, it usually scrolls multiple sections. Maybe due to the scroll inertia of the touchpad?

  6. 9 minutes ago, ZachSaucier said:

    That's quite a bit of code for a simple effect. Why not use GSAP's staggers instead of trying to predict the timing yourself?




    Yes, it seems like a lot when isolated like that, but it is a part of a much bigger system where I need a lot of flexibility. Staggers like those you proposed didn't quite cut it for my usecase unfortunately! :)



  7. Yes, sorry about the rushed post - had to get some stuff ready before the weekend and just wondered if something similar has been reported or if something came to mind :) 


    I will try to put together a proper code pen! 


    Thanks for your time

  8. On 12/6/2019 at 6:09 AM, GreenSock said:

    @unvs This is live now, in 3.0.2. ?

    First of all, thanks so much for this fix @GreenSock!


    I updated to 3.0.2 and everything worked as previous :)


    However, when I upgraded to 3.0.5 the problem started appearing again. Has there been a regression perhaps?


    A video of 3.0.4 (correct) -- the three horizontal boxes animate after eachother




    A video of 3.0.5 (incorrect) -- the three horizontal boxes just flash appear at the same time



  9. Yes, the timeline is being checked and updated through an IntersectionObserver observing elements entering the viewport, so checks are right before adding a new tween to the timeline (and right after, depending on the scrolling and elements).


    Thanks for the demo and investigative work, I really appreciate it :)

  10. Hi,


    and first of all, congrats on GSAP 3!


    I have some code running in GSAP 2 to calculate where to add in my tweens in a timeline:


        const startingPoint = tweenDuration - tweenOverlap


        if (section.timeline.isActive() && section.timeline.recent()) {
          console.log('timeline is active')
          if (section.timeline.recent().time() > startingPoint) {
            /* We're late for this tween if it was supposed to be sequential,
            so insert at current time in timeline instead */
            tweenPosition = () => section.timeline.time()
            alphaPosition = () => section.timeline.time()
          } else {
            console.log('still time')
            /* Still time, add as normal overlap at the end */
            tweenPosition = () => `-=${tweenOverlap}`
            alphaPosition = () => `-=${tweenDuration}`
        } else {
          console.log('inactive -- add to end of timeline')
          tweenPosition = () => '+=0'
          alphaPosition = () => `-=${tweenDuration}`
    In GSAP 2 this works just as I want, but when I upgraded to GSAP 3 it acts differently.
    `isActive` is never true for the timeline, even if I add a bunch of tweens initially.
    This is probably impossible to debug for you guys, but it's hard to create an example of what I mean.
    So basically my question is:
    Are there any changes to the timeline defaults or how it operates that I might look into?
    All the best,
    • Thanks 1
  11. 33 minutes ago, mikel said:

    Hey @unvs,


    Welcome to the GreenSock Forum.


    I'm not sure what effect you want to achieve.
    You forked a good pen of Eric that he has successfully created here in this post.
    So what should be different?


    Best regards


    It should work :D


    The pen I forked does not under certain circumstances, as when you scroll slowly and parts have been revealed with very short intervals and longer delays between tweens, which results in ugly bugs when scrolling erratically through sections with different number of tweens.


    If Tween1 has a duration of `2.0`

    then there is a delay of `1.5` and Tween2 is called with a position of `-=1.9`

    then there is a delay of `1.5` and Tween3 is called with a position of `-=1.9`, the tweens break.


    My fix works though, so I'm happy - thanks for looking at it anyway :)

  12. For anyone wondering or finding this later, I solved it by checking the position of the recent() tween if the timeline.isActive()



        const startingPoint = tweenDuration - tweenOverlap
        if (section.timeline.isActive() && section.timeline.recent()) {
          if (section.timeline.recent().time() > startingPoint) {
            // We're late for this tween if it was supposed to be sequential.
            // Insert at current time
            position = () => section.timeline.time()
          } else {
            // Still time, add as normal overlap at the end
            position = () => `-=${overlap}`
        } else {
          position = () => '+=0'
    • Like 1
  13. If I remove the delayedCall() and wait for the first 9 boxes to load, then scroll down so 10, 11, 12 are starting to tween, then scroll down to the next rows while 10, 11, 12 are still fading in, the rest of the tweens break.


    So, is it when I'm adding tweens with a position overlap to an already running timeline?


    See the Pen OJLwdGE by unvs (@unvs) on CodePen

  14. Hello, and first of all, thank you so much for this wonderful library!


    I'm trying to wrap my head around this weird thing I'm seeing in my app, and I feel like my head is about to explode!


    When I reveal multiple elements with `overlap`, and I delay the call of each tween, the animations get chopped.

    So if I have 8 boxes split over 2 rows in my app, the first 4 reveal perfectly, but if I scroll slowly the next ones get chopped off.

    It seems as if the timeline is not active, and I shouldn't use negative overlap, but `isActive()` returns true, and if it didn't, the animations would not overlap.


    I've tried to reduce it to an easier testcase in the codepen above.


    When the DELAY_BETWEEN_CALLS is greater than the diff between DURATION and OVERLAP the start of the animations get chopped off.


    Am I doing it wrong?


    As I'm understanding it, if I have:


    - a Tween with a duration of 2

    - a delay of 1.5 seconds

    - a Tween with a duration of 2, with overlap -=1


    it should work?


    Any help at all is much appreciated :)




    See the Pen qBWyJvq by unvs (@unvs) on CodePen