Jump to content
Search Community

SVG dual stagger causing jitter with an unidentified/unknown activity in devtools

Pete Barr test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hey all,

 

I'm getting an issue in Chrome when all my page animations stick part way through for a few milliseconds causing a jittery moment. It's during the animation of an SVG logo where I'm staggering the animation of letters of 2 words into view at the same time. I've attached the screenshot of the issue in Devtools where I believe a grey and striped area means unidentified/unknown (to DevTools) activity that is not occurring in the main thread. If I take out the second stagger the issue disappears. Has anyone come across this before or have I done anything funky below? I can't share a Codepen here unfortunately as it's very brand sensitive at the moment.

 

Thanks in advance!

 

 

hltl.set('.home-logo', { autoAlpha: 1 })
    .set('.home-logo__tm', { opacity: 0 })
    .set('.home-logo__plus-horz', { opacity: 0 })
    .from('.home-logo__plus-vert', 0.5, { scaleY: 0, ease: Power4.easeIn, transformOrigin: "center center" })
    .set('.home-logo__plus-horz', { opacity: 1, immediateRender: false  })
    .from('.home-logo__boys-border', 1.0, { drawSVG: '0% 0%', ease: Power4.easeOut}, 0.5)
    .from('.home-logo__girls-border', 1.0, { drawSVG: '0% 0%', ease: Power4.easeOut}, 0.5)
    .from('.home-logo__plus-horz', 0.5, { rotation: -90, ease: Elastic.easeOut.config(1.0, 0.5), transformOrigin: "center center" }, "-=0.35")
    .staggerFrom('.home-logo__boys-letter', 0.4, { y: 150, ease: Power2.easeOut }, 0.07, "-=0.4")
    .staggerFrom('.home-logo__girls-letter', 0.3, { y: -150, ease: Power2.easeOut }, 0.07, "-=0.9")
    .set('.home-logo__tm', { opacity: 1, immediateRender: false })
    .from('.home-logo__tm', 0.5, { x: -50, ease: Power2.easeOut });

hltl.timeScale( 0.7 );

 

perf.png

Link to comment
Share on other sites

2 things I would suggest

 

1: set up your timeline so that it can pre-record start and end values before it plays. To do that change the last line you have to:

 

hltl.timeScale( 0.7 ).progress(1).progress(0);

 

2: I really don't see anything wrong with the code, so my guess is there is some oddity or complexity in the svg that is making the browser struggle with a render or something. Do an experiment where you remove the letters in the second staggerFrom() from the svg entirely and add in some very simple artwork like 5 <circle> elements and stagger them instead.

 

 

  • Like 3
Link to comment
Share on other sites

Progress didn't seem to help. I do have the logo animation isolated in a private pen and it seems to work fine but with other animations in the full page with other animations running the issue happens, but when the second stagger is removed is only when the issue disappears. Removing other animations didn't help. Not much help I know :-(

Link to comment
Share on other sites

I replaced the letters in the SVG with basic circles like you say and it appeared to be ok. Could the transforms within in the SVG letter paths be causing an issue perhaps?

 

e.g. 

<path class="home-logo__boys-letter home-logo__boys-o" d="M216.25,166.68H212c-46.85,0-52.12,23.36-52.12,36.58v3c0,13,5.27,37,52.12,37h4.28c46.65,0,52-24,52-37v-3C268.28,190,262.8,166.68,216.25,166.68ZM244,205.34c0,8.55-5.07,19.88-29.94,19.88-25.06,0-29.94-11.63-29.94-20.08V204c0-8.45,4.48-19.38,29.94-19.38C239.13,184.57,244,195.5,244,204Z" transform="translate(1.16 1.07)"/>

 

Link to comment
Share on other sites

Could the transforms within in the SVG letter paths be causing an issue perhaps?

 

not sure, probably worth testing.

 

Is the progress 1 progress 0 a recommended thing to do in general?

 

Its useful in situations where you have a lot of concurrent tweens initializing and playing at the same time. I rarely need it.

  • Like 1
Link to comment
Share on other sites

6 hours ago, Pete Barr said:

when the second stagger is removed is only when the issue disappears.

 

What about if the first stagger is removed does the second one work.

 

Almost sounds like some kind of selector conflict, though it's unusual that it would only affect Chrome and resolve itself after a short time. 

Link to comment
Share on other sites

9 hours ago, Pete Barr said:

I can't share a Codepen here unfortunately as it's very brand sensitive at the moment.

 

I can understand this but assuming you are still having difficulties possible you could PM Jack or Carl about it with the example, then you wouldn't have to expose it publicly beyond Greensock's developers.

Link to comment
Share on other sites

Yep, @Pete Barr, I'd be happy to take a peek at a reduced test case. 

 

My only guess is that perhaps the way you've got things configured visually is causing Chrome to perform some heavy-lifting at that spot due to the overall size of the "dirty" rendering area (imagine drawing a box around the portion of the screen that must be updated/rendered). For example, maybe there's some threshold you're crossing where Chrome is like "if the dirty area is larger than 1000px in either direction, we've gotta bust it apart into multiple chunks and feed the pieces back to the GPU as textures..." 

 

Again, I'm totally guessing here. It smells like a graphics rendering thing though. I highly doubt it's related to GSAP in any way. 

 

Shoot me a PM or email if you'd like me to take a look at something. 

  • Like 2
Link to comment
Share on other sites

I can only assume you’re right. There is a fair bit going on and could be cleaner I’m sure, it just seemed strange for one small particular fragment to be removed and it cleans up. Thanks to all you guys, truly appreciate the time. I’ll PM you tomorrow. Cheers!

Link to comment
Share on other sites

I narrowed the problem down to 3 images further down the page that are not related to the animation in question, and never referred to. These images are animated later when another function is called after an interaction is done. If I delete these images the logo stagger animation is fine and that issue in devtools is cleared. The images are using object-fit:cover and are larger than its container in most responsive circumstances. If I use one from placeholder.com, a small one, the logo animation is again fine. A large one and it's slightly janky but not to the same degree. If I delete all js animations bar the logo animation with the stagger, and keep the images (as in below), the jitter remains with the issue in devtools. I have no idea what's going on :-(

 

 
<img class="islide__img" src="<?php echo get_template_directory_uri(); ?>/assets/src/images/temp/bolt.png" alt="">

 

Link to comment
Share on other sites

Hi @Pete Barr

 

Are you making sure all images are loaded before animating them. Meaning only run your GSAP or any JS code once the DOM is fully ready and teh window is loaded to prevent jank.

 

For example:

 

// wait until DOM is ready
document.addEventListener("DOMContentLoaded", function(event) {
  
  // wait until all images, links, CSS stylesheets, media assets, and fonts are loaded
  window.addEventListener("load", function(event) {
    
    // place custom JS code here
    
  }, false);
  
});

 

But for better help I would recommend you share a limited codepen example so we can test without shooting blanks.

 

Happy Tweening :)

  • Like 3
Link to comment
Share on other sites

Pretty hard to tell from the description whether it's a problem with the code or you're overloading Chrome momentarily as Jack suggested.

 

6 hours ago, Pete Barr said:

These images are animated later when another function is called after an interaction is done

 

I'm curious does the subsequent animation on the offending images execute properly.

 

6 hours ago, Pete Barr said:

I narrowed the problem down to 3 images further down the page

 

Are these images within the viewport or likely to be during the initial animation that you are having difficulty with, if not perhaps you could defer loading them until after the animation is complete, or make them invisible so the browser doesn't have to calculate their appearance immediately.

  • Like 5
Link to comment
Share on other sites

24 minutes ago, Visual-Q said:

Pretty hard to tell from the description whether it's a problem with the code or you're overloading Chrome momentarily as Jack suggested.

 

Sounds reasonable. Are you using a retina display?

 

You might be running out GPU memory. Turn on the FPS meter in the Rendering tab in Chrome/Opera dev tools, and see if you notice a huge spike in the GPU Memory during that part.

 

Psy1FlR.jpg 

  • Like 5
Link to comment
Share on other sites

@Visual-Q Yeah the animation on the images works fine, it's just a simple scale tween. The images are in the viewport under hero header and are initially 'visible' but when the user scrolls down the header animates out and the images are displayed in sequence on scroll, so they are display: none when not 'in view'. I'm using fullpage.js to achieve this by extending upon its capabilities. I can set them all to display non initially which might help, I'll give that a try. I can't defer loading them as that would break the experience.

 

@OSUblake Yeah using a retina display, does that have a bearing even though the issue is only present in Chrome? I checked out the FPS meter and there were no spikes in GPU, just a bit in the FPS as there is a few things animating at the same time.

I know it's frustrating I can't show you the issue in reality since it's related to a rebrand, really sorry guys but I really appreciate all these suggestions as always.

Link to comment
Share on other sites

@Visual-Q Yip, setting and resetting the images to display none when the hero is animating paved over my stagger jitter issue. It's always the simple answer you overlook, doh! It's still strange the issue anyway but at least this removed the jitter. 

 

Cheers to everyone, mucho mucho appreciated!!! Hopefully, this is worth all the effort with only a couple of weeks left to build the site. I'll post the link here when I've finished. Pressure is on!!

 

Ta!!

  • Like 3
Link to comment
Share on other sites

1 hour ago, Pete Barr said:

Yeah using a retina display, does that have a bearing even though the issue is only present in Chrome? 

 

It depends. Every browser handles rendering a little different, but a retina display can put a lot of strain on the browser during an animation, especially if you're using high DPI images or SVG. Setting display to none probably freed up a lot resources. 

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...