Ketaxis

Weird... In different browsers, refreshing would trigger the scroll event, without scrolling. Will have to experiment in the project more, as I could not replicate it in an example. I assumed that this is just a part of the basic functionality, and to reinforce that assumption, I also found this post: What happens in action, is that the viewport starts to stutter and teleport as I scroll down. But once all is scrolled through slowly, the same stuttering does not occur again. So far, I have seen this happening in Safari, my old phone's Chrome, my boss' iPhone and on his iOS laptop's Chrome. I am at a loss again... That gives me an idea. The effects in question use opacity. A before and after objects, that are semi-transparent, get moved in opposite directions simulating in a curtains-like fade effect. This may be the actual problem - opacity is infamously hard to process. Maybe I should try manipulating the properties of a linear gradient instead. The moving of the objects is done by using CSS variables, which are then used in transform: translate(). I have indeed read to try not to change the top, bottom, e.t.c. styles, but what about variables?

Or rather, how to be smart about initializing them? Here is the adventure I am on right now: I am using both slick sliders and images that are set to load lazy. Both are things that result in changes in the heights of objects. I could use scrollTrigger.refresh(), except that causes a scroll (why?). Some browsers do not like it when something else scrolls on its own, which required me to either handle the on scroll triggering on my own, or initialize the animations on scrolling. But wait! Doesn't ScrollTrigger automatically refresh the start/end positions of objects when their sizes change? Yes. Yes it does. But that is the key phrase - "when their sizes change". Not when their positions change. I did set a resize observer on the <main> element, but again - the refresh function causes a scroll. The first solution, as I mentioned, was to make my own on-scroll event handling (on scroll, scan all objects if they are in the viewport), but that made the timings wrong, and I neither have any idea why, nor did I have a lot of time to figure out, nor did it work very efficiently - my old Nokia 6.1 really does not like it when JavaScript is moderately used (I am curious how ScrollTrigger handles the events). Side note: on that same phone, it is funny to see how the slick sliders move smoothly, while the GSAP animations stutter and move a lot slower than they should. One more question would be how to further optimize the performance of animations. The other solution, which I am using now, is to initialize the animations when the object gets close to the view port, allowing the ScrollTrigger to calculate the start and end positions based on the current location of the respected object. This is still done from a function that gets called on scrolling every 200ms. However, this still results in initializations happening in the wrong times. I must also add, that I have one on-scroll function, which scans an array of functions, which I want to execute. This is to spare myself the trouble of writing the same code for everything that I want to happen on that event. I am not sure if that is efficient. And so, how can I ensure the correct start/end positions of objects, without calling the refresh function, despite higher object being able to push lower ones down, and keep weaker devices happy? Along with that, I will be really happy to get a better understanding of the mechanisms of GSAP, because when things start to interact in complex ways, knowing the inner workings is of tremendous help in optimizing and debugging.