Jump to content
Search Community

Performance issue in chrome Tweenmax

onlymega test
Moderator Tag

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

Hello,

I want to launch a website that is exporting html/js animations using Tweenmax library.

A few testers have reported that animation is very laggy in google chrome browser.

To reproduce this issue please open this link twice in google chrome at the same time in different tabs:

See the Pen LhkDl by onlymega (@onlymega) on CodePen

(one of four animations is always lagging).

Please help me to resolve this issue.

Thanks in advance.

 

Link to comment
Share on other sites

Hi and welcome to the forums.

 

Thanks for sharing the codepen. Unfortunately the code we would need to see and edit is part of an iframe and isn't something we can troubleshoot effectively as provided.

 

loading the iframe source into 2 tabs and even separate windows appeared to work fine.

Viewing the source of the html showed some javascript but chrome was formatting it poorly and it wasn't really legible. 

 

I did notice that you are using a VERY old version of TweenMax. I would strongly suggest you try the latest version:

 

<script src="http://cdnjs.cloudflare.com/ajax/libs/gsap/1.10.1/TweenMax.min.js"></script>

 

Please let us know if that works better.

  • Like 1
Link to comment
Share on other sites

I cracked your page open in Chrome's Dev Tools and there were HUGE paint times pretty consistently (which has nothing to do with GSAP). Literally 60ms just for an PNG image decode on almost every frame. Keep in mind that the target budget is 16.7ms for everything per frame. That's definitely the issue.

 

Chrome is known to prioritize image quality over performance when rendering, so if you're having the browser resize an image (render it at a non-native size), it's very expensive.

 

Are you saying this ONLY happens when you've got the same codepen page open in two tabs simultaneously? I wonder if that's just a Chrome bug related to doing an image resize in one tab on the same asset that's in another tab at a different size (totally a guess). There's a small chance it's related to codepen itself and the iframe stuff it does.  

 

Either way, I'm pretty confident the issue is unrelated to GSAP specifically.

 

I'd definitely recommend getting familiar with Chrome's Dev Tools and its timeline view. There are some great videos out there on YouTube by Paul Irish and Paul Lewis about that stuff.

 

Happy tweening! 

Link to comment
Share on other sites

Thank you for your replies.

I have debugged the animation issue with chrome timeline.

The problem was that chrome was trying to decode the image on every paint event.

I have attached a screenshot with two identical pages opened in chrome.

On one page image wasn't decoded each frame and framerate was good (ticker is set to 30fps) but in another tab chrome was trying to decode the image on each frame which caused low fps and high cpu usage.

The solution was to add a css property: -webkit-transform : translate3d(0,0,0);

But that is very strange because I am not using any 3d image transforms.

I think you guys need to add a fix for this issue in the next release.

If you want I can create a video with debugging process.

I am going to buy a business license now because I want to allow users to download and embed animation code created using TweenMax.

Regards

 

LWYS6kr.jpg?1

Link to comment
Share on other sites

Glad you figured it out. As far as implementing a "fix" in our next release, it's not quite that simple because applying a translate3d() to every element that's tweening could have negative consequences like:

  1. It could overload the GPU and use up too much video memory unnecessarily (which would actually cause performance problems rather than solving them). 
  2. Forcing everything into its own layer on the GPU can cause excessive traffic between the CPU and GPU depending on the type of animations you're doing. If you're only affecting transforms, it's perfect, but if you start doing other things that affect document flow, it can invalidate the layers on the GPU and cause them to need refreshing which requires more texture uploads. 
  3. Some browsers alter the type of antialiasing that occurs on 3D layers (like Chrome goes from color antialiasing to grayscale). It's subtle, but sometimes noticeable. If GSAP forced everything to go 3D, everyone would be stuck with those consequences. I'm a much bigger fan of letting the user decide which things should be forced into a 3D layer on the GPU instead of GSAP mandating it for them. 
  4. Since this isn't a "bug" in GSAP at all, and is rather a Chrome issue, it's very likely they'll fix it in a future release (Chrome is updated very regularly)

So ultimately I think it's better to leave GSAP as-is, and if you're running into that problem in Chrome (and they haven't patched it yet), then you could apply that 3d transform. We do plan on adding a "force3D" boolean special property that GSAP can recognize and do that translate3d() for you. 

 

Congrats on joining Club GreenSock as a "Business Green" member. We've got some interesting extras for club members like you that we'll be announcing sometime in the next few weeks. Stand by...

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

Sorry to revive an old post I just did not want to create a new one for this but I'm having similar issues with Chrome and animations.

 

In Firefox and even IE 10,11 the performance is flawless, always over 50fps.

 

But in chrome when 2 or more animations occur almost at the same time frame rate drops to 20fps or lower, slowly it recovers (so I guess no memory leak) but it is laggy when that drop happens.

 

I tried setting 

-webkit-transform : translate3d(0,0,0); 

but that did not work either.

 

If you have any ideas of what is going on that would be awesome
 

I have set up an example here:

http://netgfx.com/trunk/games/LCS/index.html

 

(assets and code are licensed & copyrighted)

Link to comment
Share on other sites

I'm pretty confident this has nothing to do with GSAP; let me mention a few things:

  1. Chrome is known for having a VERY slow algorithm for rendering images that are scaled down with width/height. For example, if you've got an image that's 1000px wide natively but you set its width to 400px, Chrome has to crunch all the pixels and try to smooth them out in a way that looks really nice and sharp, but that's expensive CPU-wise. If you're animating that asset and it has to keep rendering it again at new places/sizes on every frame, it's expensive. Tip: instead of setting width/height, use scaleX/scaleY so that the rendering can be done on the GPU instead. And of course if you can display images at their native sizes, always do that rather than stretching/scrunching them.
  2. It looks like you're using top/left to move things instead of x/y. Using top/left is often slower because those properties can affect document flow, thus the browser has to check to see if altering top/left affects any other elements on the page and potentially calculate layout again. However, if you use transforms (x/y), those don't affect document flow, so it's cheaper to calculate and can often be offloaded to the GPU. None of this has anything to do with GSAP, by the way. 
  3. In general, Chrome blows the doors of most other browsers in terms of JavaScript performance, so this again points to the issue being with rendering rather than GSAP's execution. 

To truly identify the performance issues with your app, it would take some focused time and research. If you need more help and would like to hire someone on a consulting basis, feel free to shoot me a PM or e-mail. 

 

We'd love to hear back if you discover something that boosts performance in your game. 

  • Like 1
Link to comment
Share on other sites

Thanks for the info, I will do a scan through my code and see if anything falls under your suggestions. I have some questions however,

 

  • If I animate x,y instead of left,top with GSAP, will the x,y be translated as relative to the parent of the element or the document (I want the latter).
  • I am using multiple TweenMax.delayedCall to "animate" or alter the background position of a div and thus creating sort of animation (explosion). Should I use another GSAP method to achieve this?
  • Are SVG achieving better performance than images on Chrome and/or GSAP?

Thanks again for your support on this.

 

By the way, latest Firefox achieves 62fps at all times (on my game) and animations look way sharper and smoother...

Link to comment
Share on other sites

"x" and "y" are like relative offsets from the element's original position in the document flow. It's just transform:translateX(...) and transform:translateY(...) from css (there are lots of articles about that online). So no, it's not absolute coordinates on the entire page.

 

I'm not entirely sure what you meant by your 2nd question - feel free to post some sample code to help us understand, but if you're using a bunch of delayedCall()s, you very well may benefit from using a TimelineLite instance and scheduling the calls in there - that way, you can control the entire thing as a whole (pause(), reverse(), resume(), whatever). Just a thought. 

 

I'm not sure if SVG would deliver better performance for images in Chrome, but I kinda doubt it. Feel free to do some tests. We'd love to hear what you find. 

 

As for Firefox being really fast, that's great but I've noticed that the tradeoff with Firefox is that its anti-aliasing algorithm is pretty bad in many cases, so the edges can look jagged. That'd make sense why they could eek out better fps if they sacrifice smooth edges.

 

Happy tweening!

Link to comment
Share on other sites

Well from a few tests that I made, there seems to be a number of things that performance can benefit from, here's the list.

 

  • If using JQuery and appending new items each time, clone() has better performance than creating new elements from the beginning
  • SVGs do offer slight improvement than images
  • Deleting elements asynchronously also helps.
  • The more element nodes in the page the worse it gets

All in all what a guy in a forum said is true and probably the solution to my problem

 

If you are dealing with over 1000 elements, go with Canvas instead.

 

Although disappointing...

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.
×
×
  • Create New...