To heavy animation

[mk1]

Good morning everybody!

 

I have build few animations using pure TweenMax, and right now one of them is ultra heavy for the processor, below I am pasting it's code:

var navExpander = new TimelineMax({paused: true});


jQuery(document).ready(function ($) {

    var sideBarContent = $('.adminArea__sidebar'),
        sidebarFlag = $(".sidebarFlag"),
        contentFlag = $(".contentFlag"),
        navFlag = $(".navFlag"),
        pathLenght = 0,
        canCloseTheSidebar = $('.canCloseTheSidebar');

    function checkAnimationPathLength() {
        var sidebarLenght = sideBarContent.outerWidth(),
            pathLenght = sidebarLenght - 80,
            pathLenghtContent = pathLenght;
        console.log(sidebarLenght, pathLenght);

        sidebarFlag.removeAttr('style');
        contentFlag.removeAttr('style');

        //GSAP timeline put here on purpose, cause of GSAP's value caching before they are updated

        navExpander.clear();
        navExpander.invalidate();

        navExpander
            .to('.adminArea__sidebar__content .toFadeOut', 0.2, {autoAlpha: 0, ease: Power4.easeOut})
            .to('.adminArea__sidebar__content .profilePhoto', 0.8, {scale: 0.4, xPercent:-50, left:"50%", y: '-=90', ease: Back.easeInOut.config(1.2)}, "Same tween")
            .to(sidebarFlag, 0.8, {
                width: '-='+pathLenght,
                ease:  Back.easeInOut.config(1.2)
            }, "Same tween")
            .to(contentFlag, 0.8, {
                width: '+='+pathLenghtContent,
                ease:  Back.easeInOut.config(1.2)
            }, "Same tween")
            .to(navFlag, 0.8, {
                width: '+='+pathLenght,
                ease:  Back.easeInOut.config(1.2)
            }, "Same tween")
            .to('.adminArea__sidebar__content ul li a.active', 0.8, {className: '-=active', ease: Power4.easeOut}, "Same tween")
            .to('.adminArea__sidebar__content ul li a span.bl-icon--sidebar', 0.8, {xPercent:-50, left:"50%"}, "Same tween")
            .to('.bottomNav button.canLogOut', 0.8, {backgroundColor: '#607d8a', ease: Power4.easeOut}, "Same tween")
            .to('.bottomNav .toFadeIn', 0.8, {autoAlpha: 1, xPercent:-50, left:"50%", ease: Power4.easeOut}, "Same tween")
            .to(canCloseTheSidebar, 0.4, {xPercent:-50, left:"50%", rotation: '-=180', onReverseComplete: function(){
                TweenLite.set(this.target,{clearProps:'all'});
            }}, "Same tween");


            //.to('.adminArea__sidebar__content .profilePhoto', 0.8, {y: '-=90', ease: Back.easeInOut.config(1.2), delay: 0.2})

            //.staggerTo('.staggerToTop', 0.6, {y: '-=80', ease: Back.easeInOut.config(1.2)}, 0.1, "Same tween");

            //.to('.adminArea__sidebar__content .toFadeIn', 0.8, {autoAlpha: 1, ease: Power4.easeOut});
    }
    checkAnimationPathLength();
    $(window).on('resize', checkAnimationPathLength);
    //Expand the sidebar

    var adminStatusFlag = false;
    var inProgressAdminBar = false;

    canCloseTheSidebar.on('click', function () {
        if(adminStatusFlag === true && inProgressAdminBar === false){
            inProgressAdminBar = true;
            navExpander.reverse();


            setTimeout(function () {
                inProgressAdminBar = false;
                console.log('Sidebar animation finished');
                adminStatusFlag = false;
            }, 900);

        }else if(adminStatusFlag === false && inProgressAdminBar === false){
            navExpander.play();


            setTimeout(function () {
                inProgressAdminBar = false;
                console.log('Sidebar animation finished');
                adminStatusFlag = true;
            }, 900);


        }
    });



    TweenMax.to('#sideBarKiller', 2, {x: '-=6', ease: Back.easeIn.config(1.7), yoyo: true, repeat: -1});





});

Can you please guys tell me if there is something bad about the code structure what may cause my processor to shoot through a roof?

 

As well before I will build any samples on codepen, do we have some sources on optimization, performance, etc. ? I really want to find the solution on my own, or try at least

[Jonathan]

Hello mk1 and welcome to the GreenSock Forums!

 

When you view your animation in the browser inspector, do you see the elements animating using matrix(), translate3d() or matrix3d(). The reason being is that if it is only using matrix(), than it is not using hardware acceleration (GPU). There are minor tweaks you can do to get it to look smooth with no jank (lost frames). But for that we need to test your code live in the browser. Sometimes you can add rotation:0.01 to any tween that is animating scale, x, or y so you can have GSAP use matrix3d() to force a new rendering layer for buttery smoothness.

 

To better help you can you please create a reduced codepen demo example. The reason being is that it will be hard to see what type of performance issues you are having without seeing your code live and editable, as well as seeing what your CSS looks like.

 

 

Thanks 

[GreenSock]

The most expensive stuff I saw in your code was:

1. The className tween (those literally have to iterate through every property, isolate what has changed between states, and record starting/ending values). I generally try to avoid className tweens if you can - it's much cleaner and more performant to specify the values you want changed. 
2. The "resize" hander. That can get called many times while the user drags the window bigger/smaller, and you're invalidating() and recreating all your tweens each and every time. If I were you, I'd throttle that so that it waits until the user stops dragging (a certain amount of time has elapsed with no more changes) before firing that. 
3. The "width" tweens. "width" is just expensive for the browser due to repaints, layout reflow, etc. Oh, and calling jQuery's "outerWidth()" is pretty expensive too. 

Typically when you're seeing poor performance, the biggest culprit BY FAR is browser rendering which has absolutely nothing to do with GSAP. In other words, GSAP could change the property values in 1ms, but it might take 100ms for the browser to then calculate all the new pixels and repaint the screen. So I'd focus your energy on minimizing the load on the browser in terms of graphics rendering. 

[mk1]

Thanks a lot for the tips guys, working on it right now. Will post the outcome asap

[mk1]

Hmmm... I striped down the code to the minimum:

jQuery(document).ready(function ($) {

    /*
     ***************** Expand and Disband Sidebar **********************
     */
//Floating arrow Yoyo Tween
    var canCloseTheSidebar = $('.canCloseTheSidebar'),
        topNav = $('#topNav'),
        closeSidebarTimeline = new TimelineLite();

    closeSidebarTimeline.to(canCloseTheSidebar, 2, {x: '+=6', ease: Back.easeIn.config(1.7), yoyo: true, repeat: -1});




(function ($) {
    (function ($) {
        $.fn.sidebarExpander = function (options) {

            var settings = $.extend({
                // These are the defaults.
                topNavId: '#topNav'

            }, options);

            var inProgressFlag = false,
                isOpenFlag = false,
                triggerButtonW = $(this).outerWidth(),
                triggerButtonNewWidth = triggerButtonW + settings.extendWidthBy;

            return this.on({
                mouseenter: function () {

                    TweenMax.to($(this), 0.4, {width: 280});

                },
                mouseleave: function () {


                    TweenMax.to($(this), 0.4, {clearProps: 'width'});

                }
            });
        };
    }(jQuery));

    var sidebar = $('#sidebar');
    sidebar.sidebarExpander();

}(jQuery));



});

Preview: http://property-backend.beectrl.a2hosted.com/branches/sidebar_animation_js/

 

 

Here's the css animation, much more complex and still much better working...

Preview: http://property-backend.beectrl.a2hosted.com/

 

I thought that CSS animations are much less smooth than GSAP

 

 

EDIT: I have add rotation as @Jonathan suggested and I think it improved the animation a lot, but it's still not butter smooth, at least on my Mac (Pro, mid 2015 )

[Carl]

Please post a reduced-test case using CodePen that only contains the code necessary to replicate the problem you are seeing. 

Its very difficult to test any assumptions on a live site with so much code. FWIW i looked at both links and could not discern any difference.