Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Guest kirkjg

Achieving holy-grail level performance

Recommended Posts

staging.mkeballet.org

 

Hello GSAP crew. I've got a site here that does full page xPercent tweens(inspired by the answer to my previous question - thanks Blake), coupled with drawing an SVG path, and a few other things. On mouse wheel, a function called goNext() or goPrev() fires. Within those functions are the individual functions that kick off the parts of the cover transition - drawing the circle forward/backward, transforming the text in and out, and sliding the cover xPercent in and out.

 

Everything is going great, on at least the user facing side, even on retina screens. Except when you make the screen larger than an average laptop. On larger screens, the cover images are of course larger. And when they "clip" in and out, the red circle path chugs as it draws. 

 

If you inspect the sources, you'll find the JS file in js/custom/mkeballet.js. I've minified the irrelevant sections, and tried to comment what the relevant hunks do. The goNext() function is where things come together for this example.

 

So in summary, my question is do you see anything about the way I'm organizing/writing my GSAP code that is counter-intuitive, or am I just trying to do too much that jank is inevitable? 

 

I've been here https://developers.google.com/web/tools/chrome-devtools/memory-problems/?hl=en

 

But I'm not that good at memory monitoring yet so I haven't been able to discern anything useful yet.

 

Thank you!

See the Pen by (@) on CodePen

Link to post
Share on other sites

Hello kirkjg, and Welcome to the GreenSock forum!

Keep in mind that animating many DOM elements or SVG DOM elements will always have low performance compared to animating canvas or canvas WebGL. SVG is DOM based so the browser has to calculate or compute the existing layout and then paint and composite into a sort of bitmap. So it will be slower than animating with canvas which is like drawing frames on each browser refresh or tick. It doesn't have to worry about all that HTML or SVG markup for canvas.

 

Also keep in mind that SVG can not animate using hardware acceleration (GPU). So it it has to animate using the CPU which has its limits. But regular non SVG DOM elements can animate using the GPU and offload the rendering to your graphics card and animate the elements on their own rendering layer for a smoother jank (lost frames) free animation.

 

The main <svg> element can be animated using 3D transforms and use the GPU. But not its inner children. They are bound to only animate using 2D transforms since its SVG 1.1. Eventually when SVG 2.0 comes out SVG will support CSS 3D transforms.

 

Sometimes it better to wrap your <svg> element with a div and then animate the <div> tag so you can get better performance.

 

If you are having a specific issue. i would recommend to isolate your issue or jank in a codepen so we can test your code live to better help you.

 

Happy Tweening!

:)

  • Like 3
Link to post
Share on other sites

Thanks for posting your site. I wish I had more time to dig in a do performance monitoring but that can be very time consuming, especially on a site of this complexity. Very impressed though by what you have done. It looks beautiful and seemed to run quite well on my largish browser on a 27" monitor.

 

Unfortunately SVG can be a real dog when it comes to performance. Browsers just aren't good at recalculating and rendering all that path data at 60fps. I wish I could provide some silver bullet answer.

 

Keep up the great work

  • Like 3
Link to post
Share on other sites

SVG animations can be very CPU intensive, but what you're doing doesn't look that complex, so there's probably another issue at play here.

 

I looked at your JavaScript file, and noticed requestAnimationFrame calls everywhere. You need to be careful about how you make these calls because they are added to a queue. Previous request are not cancelled, so you can have the same callback being called multiple times within a frame.

 

Check this out. When you scroll, it's going to show the time since last the last update. If it's 0, that means the callback is being called more than once within a frame, which is probably what's killing your performance.

See the Pen f977bfbc2cf9dfb7a0a07f088f70ee94?editors=0010 by osublake (@osublake) on CodePen

 

An easy way to prevent that to is to keep a reference to the request, and use that as a flag. 

See the Pen db6bef4b03721d37183275cdc41ee260?editors=0010 by osublake (@osublake) on CodePen

 

Instead of managing all these request, it might easier to use GSAP's ticker, and have it run all your updates in a single callback.

See the Pen 78d479fda6f074d7a5c63790a1fd28ae?editors=0010 by osublake (@osublake) on CodePen

 

This probably won't make a difference performance-wise, but you should replace all your setTimeout calls with delayedCall as they use GSAP's ticker, and won't get out of sync if the user changes tabs.

// Replace this
setTimeout(function() {
  window.requestAnimationFrame(slideIn);
},100);

// ...with this
TweenLite.delayedCall(0.1, slideIn);

There's other little stuff that might help, like replacing your jQuery fadeIn/fadeOut animations with GSAP, but for now I'd focus on fixing your animation frame calls.

  • Like 2
Link to post
Share on other sites

You all are awesome, I love how much there is to learn just by starting a thread here. I still have some code considerations to make, particularly regarding Blake's advice on delayedCall().. Just wanted to let you know https://www.milwaukeeballet.org is launched. I hope you like it.. enough to put it in the showcase perhaps ;)

Link to post
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.

×