Rendering Lags in Safari

[themepunch]

I recognised using stagger in Safari the pre- rendering time can take 6x so long than in Chrome or Firefox.   Depending on some further options and combination i.e with cycle it goes up to a 9+x.    For dynamic calculated Animations based on interactions  these delays and lags in Safari are too big.

 

If you click on the "chars" button in the Example below, and open the Inspector, you will see the rendering time differences between Safari and Chrome.   

(62,87ms vs  344,54ms)

 

Do you have an idea why this happens, and if there is any way to avoid it ? 

 

Thanks and Greetings ! 

 

See the Pen MXopPe by themepunch (@themepunch) on CodePen

[Carl]

I don't think the problem lies in GSAP or staggered animations.

 

When you click you are using SplitText to break that text into characters and words and then inject 100+ new DOM nodes (with their own inline styles) into the DOM. In addition, there is also logic that needs to run to preserve the styling of nested tags like <span>, <strong> etc.

 

All that has to happen before any animation comes into play and THEN the staggered animation needs to create 100 or so more from() tweens, which involves assessing and recording start and end values. 

 

And to make matters a bit worse, by using 3D transforms, each of those 100 or so nodes need to be layerized / sent to the gpu.

 

I suspect that's a lot of work for browsers to do instantly. I'm not quite sure why Safari takes more time than other browsers, but I don't think this is a problem inherent to staggered animations. My guess is Its more related to using SplitText, the amount of text you are splitting and the amount of animations you are creating.

 

My advice would be to split the text before you need to animate it if at all possible.

[themepunch]

Hi Carl,

 

i think you get me wrong here. I dont claim about the overall time it takes, i can totally understand what happens in the background, and i am aware that using split text  will have influence on the DOM creating hundreds of elements and tweens.  The Question was,  if you have an idea, why IE Edge needs almost 12 times longer than Chrome, and Safari around 9 times longer.   Browsers are different,  And if so, maybe there are better way to have different paths in the engine which use more optimal calculations for Safari and Edge than for Chrome and Firefox.  Maybe it is worth to take a look on  that ?

 

Thank you for your feedback again and greetings from Cologne,

 

Krisztian

[GreenSock]

Yeah, browsers can all be pretty different performance-wise. The only thing I can think of that may be different in Safari when it comes to GSAP is that in order to work around some Safari bugs, GSAP sets a z-index on elements that are having transform-related animations applied. And for Safari 6 and earlier, it'll set WebkitBackfaceVisibility (again, to work around bugs). 

 

Other than that, perhaps some browsers handle the promotion of transformed elements to layers more efficiently than others. So you could try setting force3D:false to see if that helps anything (though it may actually hurt in some cases). Or set it to true and see what effect that has. 

 

I hope that helps!

[themepunch]

Thank you for the clarification here, really appreciate it.  Indeed "disabling" 3D would hurt in the most of the case how Customers use our product, so will check if i can somehow reduce the parameters and needs on splits on demand, or optimize  DOM Manipulation by preparing things in "CPU Free time". 

 

Thanks again and wish you a great day ! Greensock forever ! You are the best ! 

 

Cheers from the ThemePunch Team.