Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @mvaneijgen Thanks for your response and your advice (and sorry for the late response, I had a vacation get between me and the project). I solved the issue now by calculating the "missing" extra height of the container (the document.body in this case) and adding it to the body, so element can be scrolled to top. Here is an updated sketch: https://codepen.io/trych/pen/ZEVYQVr Upon further fiddling I figured out that I do not even need to calculate the exact size, I can just add any big enough value (so anything bigger than window.innerHeight) temporarily, then it has enough space to scroll and the scrolling can be calculated correctly by the scrollTo plugin. Thanks for your help everybody!
  2. Hi there, thanks a lot for the responses already. Unfortunately the suggested changes are not really a solution to my issue, because they only work due to the scrolling happening after the resizing (which is something that I could also get to work by simply applying a delay to my implemenation). I would need the scrolling and resizing to happen at the same time. So what I am asking about is really, how to continously update / recalculate the target during the tween to have all this happening in one fluid motion. Does anybody have an idea, how this could be solved? Thanks!
  3. Hi there, I have a setup where I grow section upon clicking on them and scroll them to the top of the window via gsap's scrollTo plugin. Generally this works fine, however, there is an issue with sections that are initially not able to be scrolled to the top (due to their limited height). It's a bit difficult to explain, but might become obvious once you look at the provided example. When you click on any of the top three sections (red, green, blue), everything works fine, however when you click on either of the bottom sections (yellow, cyan), they do not scroll to the top, as they cannot be scrolled to the top initially. The issue is most obvious when clicking on the yellow section: the section grows to 100vh height, yet is unable to be scrolled to the top. Now, obviously gsap seems to calculate the target scroll position at the beginning of the animation and then does not update it anymore during tweening. Is there any way to fix this issue by maybe have gsap continously recalculate where the top of the (resizing) element is and adjust the tweening accordingly? Thanks a lot!
  4. How would I do that? Like this? onLeft: self => { self.event.preventDefault(); } I'm not quite sure I understand. Is this because the preventDefault would only be part of the debounced action? Would it then make sense for expensive operations to create two Observers? One that only prevents the default and is not debounced and one that executes the actual action and is debounced? Or would that not work? Another question: the `allowClicks` property seems to be another undocumented property. Does this one take care of preventing click events on touch/drag style events? Because that is what I was actually trying to prevent and that might be helpful for me in my current project.
  5. Quick side question: Is this the "official" way to add a preventDefault to the Observer events? This options seems to be documented nowhere. What about stopPropagation? Does it work the same?
  6. While it seems that `.ratio` has been in the docs for a while, I think it would also be helpful to add a little info to the `.progress()` sub page that this gives you the value before easing. I thought I was going insane here, because I didn't know that.
  7. Ok, that is fairly confusing, if you don't know that that's how it works. I guess in that specific case it would have been more helpful if gsap refused to tween, but I understand why this parsing will be helpful in many cases. Yeah, the confusing part was mainly that the pixi setter worked with a simple number as input. Yes, although I read somewhere else on the forum that this only really works for simple pixi stuff. So I was not expecting it to work on one of pixi's fiter plugins. Might be wrong though. Anyways, I got it to work now. Thanks a lot for the help and the explanations!
  8. Oh, ok. This does indeed work. Now after investigating, why it didn't work in my case, I realize I actually did this: let settings = { size: pixiFilter.size }; gsap.to(settings, { size: 80, snap: "size", duration: 5, onUpdate: function() { console.log(settings.size); } }); And this does not work, because the pixiFilter actually does not return a number but an Array with length of two, like [10, 10]. Since gsap just started happily tweening (starting from the correct size value), I didn't even suspect that it couldn't be a number. Apologies, even though I assumed this simple case would have worked without a minimal demo, I now see I should have posted one ... 😞 So, what does gsap actually do in this case? Does it grab the array's first value and uses that for tweening? And should snap maybe also work in these cases? I mean, as long as gsap starts interpolating, as a user I would expect it to respect any additional settings as well.
  9. Ok, the snapping does not even work on a generic object: let settings = { size: 10 }; gsap.to(settings, { size: 80, snap: "size", duration: 5, onUpdate: function() { console.log(settings.size); } }); This gives me floating point values. Is the snapping plugin maybe broken in more recent releases? I am using v3.11.1 Edit: Sorry, this does indeed work, my specific example was slightly different, see my post below. As a workaround I could solve this with Math.round() like you suggested. let settings = { size: pixiFilter.size }; gsap.to(settings, { size: 80, snap: "size", duration: 5, onUpdate: function() { pixiFilter.size = Math.round(settings.size); } }); Should the non-working snapping be reported as a bug somewhere?
  10. How can I get the current interpolated value in my onUpdate callback?
  11. @Rodrigo, thanks for looking into this, and sorry for not responding earlier, somehow I missed that there was a reply. I gave your solution a try, however, it does not seem to work, unfortunately. Here is what I did: gsap.to(myFilter, { size: 80, snap: "size", duration: 5, onUpdate: function() { console.log(myFilter.size); } }); The onUpdate logging (for debugging) still reveals that the size is set to float values: Any idea what I could be doing wrong? Or how else to round this to whole numbers? Thanks!
  12. Hi there, I am trying to animate a filter in pixi.js using gsap. However, it seems that this filter's size property only works with integer values. So I would my gsap tween need to animate from let's say 10 to 80, but only to return integers for the inbetween values. How is this possible? gsap.to(myFilter, { size: 80, duration: 5 }); Thanks!
  13. I don't seem to be able to test this in my local setup (as the trial warning kicks in), but using it in the Codepen it seems to have fixed it! Thanks a lot for looking into this, I am really impressed by the speed and helpfulness of the Greensock team!
  14. Ok, understood, thank you. It would probably be a good idea to be a bit more explicit in the ScrollSmoother docs then, because it says <!--- ALL YOUR CONTENT HERE ---> and with all the magic that ScrollSmoother is doing, I was not sure, if it maybe also takes care of fixed positioned elements.
  15. @OSUblake Thanks for looking into this. I am still observing this, even when I remove the duration property from the snap object, although it seems to happen less frequently (and just once each time it happens, not endlessly in succession). As I said, it seems to be much easier to observe when you use it on a full size window. On another note: I noticed that fixed position elements that are included into the wrapping containers are not behaving like fixed position elements anymore once the plugin kicks in, i.e. they move out of the viewport once I start scrolling. Is this intended and am I supposed to move those elements outside the wrapping container (docs say to include ALL content within the wrappers)? Or might this be another bug?