ScrollTrigger seemingly with different behavior when horizontal

[pedrobear]

Hi folks,

 

I'm just getting to GSAP via this lovely, impeccable little UI below. Since then I've setup it locally and tweaked things, changed elements, etc...

 

What I can't seem to wrap my head around is: why do things start behaving a little off if I change that ScrollTrigger to be horizontal?

 

Like, I'd like this UI to allow for normal horizontal scrolling, instead of emulating from vertical. Initially everything seems to be working ok when I change that boolean, but the scroll becomes way too fast, and navigating via the keyboard becomes a bit erratic (the snapping is clearly off).

 

Any pointers are appreciated, thank you!

See the Pen WNRvqJP by jh3y (@jh3y) on CodePen

[mvaneijgen]

Hi @pedrobear welcome to the forum!

 

Can you share a demo with your changes so that we can see your findings in action. ScrollTrigger is made for scrolling vertical and there are some features build in to check if things that move horizontal to check if you scroll past them, but a lot of web users don't have a way to scroll horizontal. But the beauty of GSAP is you can build what ever you like if you put in enough elbow grease. What springs to mind is the Observer plugin with with you can watch for scroll events and then do logic based on that. https://gsap.com/docs/v3/Plugins/Observer/

 

But again we would love to see what you already changed so that we can help you debug. Hope it helps and happy tweening! 

[pedrobear]

Hi @mvaneijgen!

 

Thanks so much for the quick reply, looking at the Observer right now.

 

My bad I didn't post the change in 1st place, here it is:

 

See the Pen eYapMdB by pedrobear (@pedrobear) on CodePen

 

This is the exactly same Codepen above, just with horizontal: true and removing the vertical mouse icon. I've changed a lot more since since, but I think that will detract a bit from my original question – just curious as to why the scrolling is a bit more sluggish with this setting, using a MacBook touchpad at least.

 

And more importantly, if you click on it and use arrow keys to navigate, the 1st Codepen is perfectly smooth, whereas with the 2nd we can see it overscrolls a bit and then snaps back. Do you know if the trigger work differently for horizontal scrolling, or is this just related to how the viewport has different dimensions?

 

Thanks,

 

[GreenSock]

Hi @pedrobear. There's a lot of very custom logic in that CodePen demo, and it's well beyond the scope of help we can provide for free in these forums, but if you'd like to isolate a very specific problem in a much simpler version, we'd be happy to take a peek and help with any GSAP-specific questions. It looks likely to me that the snap-back with the arrow functionality has to do with logic flaws in where you're animating to (calculations). As for being sluggish, there are a lot of factors with that (performance is a very deep topic), but one possibility is that browsers have rendering engines that are optimized for vertical scrolling, not as much horizontal scrolling, so you may be hitting some browser-specific optimization limitations. For example, I know that if you have elements that go beyond a certain width, the browser forces it to get broken into multiple tiles for the graphics renderer, and switching between them can be a little expensive. None of that has anything to do with GSAP. 

 

Good luck!

[pedrobear]

Ahh, makes total sense! Thank you folks for the excellent input, I'll share a more specific/targeted example if anything else comes up. Appreciate it!