Infinite horizontal scroll marquee - pause on hover - resume in same direction

[adapfityDesigns]

I forked a pen which was accomplishing almost exactly what I wanted, except it only had one marquee line of text, going in one direction.

I want to have multiple lines, with each alternating line moving in the opposite direction.

 

The problem is that when the timeline with a reversed direction is hovered, on mouseleave the animation returns to default direction.

 

Can anyone take a look and let me know how I can configure the reverse direction timelines to continue animating in the reverse direction after hovering?

 

Thank you so much!

 

 

See the Pen MWxjKxG by Colin-Safranek (@Colin-Safranek) on CodePen

[Rodrigo]

Hi @adapfityDesigns and welcome to the GSAP Forums!

 

Just use the tickerDirection boolean in your mouseleave event handler to conditionally set the timescale to either 1 (forward) or -1 (backwards):

link.addEventListener("mouseleave", () => gsap.to(tl, {
  // Conditionally set the timescale
  timeScale: tickerDirection ? -1 : 1,
  overwrite: true
}));

That seems to work the way you intend.

Hopefully this helps.

Happy Tweening!

[adapfityDesigns]

Yes! Thank you so much for the quick response! And yes that works perfectly. Much appreciated  

[adapfityDesigns]

@Rodrigo Wondering if you can take a look at this implemented on a production site:  

 

https://www.pinnacle-exp.com/capabilities/#11374-brand-space-ribbons

 

I was able to achieve the desired effect, but I've noticed sometimes the animation lags and gets choppy, especially on mobile devices. Is there anything I could do to improve the performance of this particular animation? 

 

If you inspect the page and search for // Brand Space Marquee Animations you'll find all the relevant JS in very readable inline script. 
Let me know what you think. It would be very much appreciated. Cheers!

[Rodrigo]

Hi,

 

The code looks OK, nothing wrong there.

 

A lot of performance problems are down to how browsers and graphics rendering work. It's very difficult to troubleshoot blind and performance is a DEEP topic, but here are some tips: 

1. Try setting will-change: transform on the CSS of your moving elements. 
2. Make sure you're animating transforms (like x, y) instead of layout-affecting properties like top/left. 
3. Definitely avoid using CSS filters or things like blend modes. Those are crazy expensive for browsers to render.
4. Be very careful about using loading="lazy" on images because it forces the browser to load, process, rasterize and render images WHILE you're scrolling which is not good for performance. 
5. Make sure you're not doing things on scroll that'd actually change/animate the size of the page itself (like animating the height property of an element in the document flow)
6. Minimize the area of change. Imagine drawing a rectangle around the total area that pixels change on each tick - the bigger that rectangle, the harder it is on the browser to render. Again, this has nothing to do with GSAP - it's purely about graphics rendering in the browser. So be strategic about how you build your animations and try to keep the areas of change as small as you can.
7. If you're animating individual parts of SVG graphics, that can be expensive for the browser to render. SVGs have to fabricate every pixel dynamically using math. If it's a static SVG that you're just moving around (the whole thing), that's fine - the browser can rasterize it and just shove those pixels around...but if the guts of an SVG is changing, that's a very different story. 
8. data-lag is a rather expensive effect, FYI. Of course we optimize it as much as possible but the very nature of it is highly dynamic and requires a certain amount of processing to handle correctly.
9. I'd recommend strategically disabling certain effects/animations and then reload it on your laptop and just see what difference it makes (if any). 

Ultimately there's no silver bullet, like "enable this one property and magically make a super complex, graphics-heavy site run perfectly smoothly even on 8 year old phones" 

 

Maybe try disabling some stuff on devices, make it easier for the limited hardware power small devices have to handle this.

 

Sorry I can't be of more assistance but this is mostly about trial and error. Try stuff and when you have something that works the way you intend (or as close as possible) stick with that.

 

Good luck with your project!
Happy Tweening!

[adapfityDesigns]

Ok, thanks for this list @Rodrigo

 

Regarding the lazy loading of images. This feature is widely recommended, especially for the SEO benefit of meeting the “defer offscreen images” recommendation from the Google PageSpeed test. Are you saying this actually creates a page performance issue? Is it worth it to disable a lazy load implementation do you think?

 

Thanks!

[Rodrigo]

Hi,

 

I'm not saying that lazy loading is the sole culprit of this. As mentioned there are a bunch of situations that can lead to performance issues, lazy loading can be one of them if images are being lazy loaded and then animated as you scroll. My previous post is a list that has been created with the most common performance issues and some suggestions so users can try some of them in their scenarios and see if they help. For example did you tried will-change: transform in the elements being animated?

 

The main point of my previous post is that performance issues are rarely a GSAP related issue and most of the times they fall under the category of browser rendering.

 

Happy Tweening!