Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
SUPERKODERS

SVG layout trashing issue

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

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

image.thumb.png.4b1e3f37f9566bbefa1bd84c72f30824.png

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 (michal.matuska@superkoders.com)

 

Link to comment
Share on other sites

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? 

  • Like 2
Link to comment
Share on other sites

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!
 
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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/

 

 

  • Like 5
Link to comment
Share on other sites

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.

  • Like 1
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.

×