bug SVG layout trashing issue

[SUPERKODERS]

Hi,

 

I find out very bad performance issue when I am animating more SVG elements together.

I have some knowledge how browser rendering performance works and then I discovered thru DEV timeline that it is layout trashing.

You can try test it on live site here https://storyous.com/cz/ (animation in top banner)

 

Here is a timeline

bottom purple colls are like a usually layout trashing looks

 

I investigated more.

First I was very surprised that every svg transform animation going thru attribute. I saw some time before that svg animation went with style transform also like normal html node. After few minutes I find out why. https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/plugins/CSSPlugin.js#L1200

It is some workaround. Do somebody know why? From comment it is not clear.

 

Layout trashing is caused by

reading BBOX

https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/TweenMax.js#L4293

and after setting attribute

https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/TweenMax.js#L4307

in loop with X elements

 

In code should by some workaround like FastDom https://github.com/wilsonpage/fastdom

Can somebody look on this issue? Can I help with something?

 

Thanks,

Michal ([email protected])

 

[GreenSock]

It looks like you must be doing percentage-based transforms which isn't supported in browsers natively (at least according to the SVG spec from what I understand), thus GSAP must perform those calculations. Do you really need to use percent-based transforms? Maybe try doing the conversion initially yourself and feeding in px-based values instead. GSAP could, of course, just do the initial conversion and never query getBBox() again, but that would break if the size of the element changes at all during the tween. See what I mean? So GSAP must take a cautious (reliable) approach rather than just assuming that the size won't change. But if you, as the developer, know that you're not going to change the size during the course of the tween, you could just figure out the value in terms of px (or SVG units actually) and feed that in instead. 

 

See what I mean? 

[SUPERKODERS]

Yes I understand.

In animation it is using bezier with data from pathDataToBezier,

BUT maybe problem is this

 

TweenLite.set($dots, {
  xPercent:-10,
  yPercent:-10,
  transformOrigin:'50% 50%',
});

 

before animation start. We will try it without this and I will let you know.

Thanks for quick respond!

 

[SUPERKODERS]

You have right. Relative percentage values did it. Layout trashing is gone.

We now see other improvements but they are not connected to GSAP.

Thank you so much.

Best regards, Michal.

[OSUblake]

Your SVG is almost 4,000 lines of code with 10,000 DOM nodes. A lot of it doesn't even look important, like all these empty path coordinates.

 

<path fill="#C9D0D2" d="M637.1,397.9C637.1,397.9,637.1,397.9,637.1,397.9C637.1,397.9,637.1,397.9,637.1,397.9
 C637.1,397.9,637.1,397.9,637.1,397.9C637.1,397.9,637.1,397.9,637.1,397.9C637.1,398,637.1,398,637.1,397.9c0,0.1,0,0.1,0,0.1
 c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0
 c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0
 c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0
 c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0
 c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0c0,0,0,0,0,0
 c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0
 c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0,0,0-0.1,0c0,0,0,0-0.1,0c0,0,0,0-0.1,0c0,0,0,0-0.1,0c0,0,0,0-0.1,0c0,0,0,0-0.1,0
 c0,0,0,0-0.1,0c0,0,0,0-0.1,0c0,0,0,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0
 c0,0,0,0-0.1,0c0,0-0.1,0-0.1,0c0,0,0,0-0.1,0c0,0-0.1,0-0.1,0c0,0,0,0-0.1,0c0,0-0.1,0-0.1,0c0,0,0,0-0.1,0c0,0-0.1,0-0.1,0
 c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0-0.1,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0
 c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0
 c0,0,0,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1,0c0,0,0,0,0,0c0,0,0,0-0.1,0c0,0,0,0,0,0c0,0,0,0-0.1,0
 c0,0,0,0,0,0c0,0,0,0-0.1,0c0,0,0,0,0,0c0,0-0.1,0-0.1-0.1c-0.5-0.3-0.8-0.7-0.8-1.1l0.6,7.5c0,0.8,0.4,0.8,1,1
 c0.6,0.2,1.3,0.2,1.9,0.1c0.7-0.1,1.1-0.2,1.1-1L637.1,397.9C637.1,397.9,637.1,397.9,637.1,397.9z"></path>

 

 

You might want to run your SVG through an optimizer, like SVGO.

https://jakearchibald.github.io/svgomg/

 

 

[SUPERKODERS]

Thanks Blake for great tip. You have right. I investigated only performace but no data.

I will tell it to my colleague. It is a pity I did workshop to my team about this some time before.