Jump to content
GreenSock

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

Performance 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

I've included TweenLite, the CSS plugin and the ease pack into my project via RequireJS.

 

If I open up Chrome dev tools I can see that TweenLite is firing "Animation Frame Fired" events continuously, with each one causing a "Composite Layers" repaint. This is without executing a single tween. The memory footprint of the page sawtooths between about 5MB and 8MB inbetween the GC kicking in and my Macbook Air's fan starts to spin up!

 

If I don't load in TweenLite and its add-ons these issues disappear. What's going on here? Is it anything to worry about?

 

Thanks!

Link to comment
Share on other sites

I'm curious about why you think it's causing a repaint - I checked Chome dev tools too when things are idling (no tweens in progress) and there were absolutely no repaints. The only thing happening when no tweens are in-progress is the ticker is updating its time and the 2 root timelines which should be very minimal in terms of CPU usage. 

 

However, in version 1.9.1 we are aiming to power-down the ticker when it's not needed - see http://forums.greensock.com/topic/6773-requestanimationframe-ticker-keeps-on-going/

 

There's a preview of 1.9.1 files there - would you mind giving those a shot? 

Link to comment
Share on other sites

Hey, here's a screenshot of Chrome dev tools. The only JS being loaded into the page are TweenLite, CSS plugin and the ease pack. I'm using Chrome 27.0.1430.0 dev, and a late 2011 Macbook Air, OSX 10.8.2.

 

As you can see, each request animation frame call from TweenLite seems to trigger Chrome to composite layers. This definitely starts to tax something in my hardware because the fans spin up.

 

I will try 1.9.1 ...

 

Screen%20Shot%202013-03-15%20at%2010.51.

Link to comment
Share on other sites

So with 1.9.1 I'm still seeing the RAF into composite layers oddness, but as expected the RAF idling soon kicks in and things calm down. My fans don't spin up and things generally seem a bit more responsive.

 

I'll continue with 1.9.1 for now, and let you know of any issues. I can try and further investigate the composite layers repaint if you like, but not sure how to dig into it?

Link to comment
Share on other sites

It is definitely strange for Chrome to repaint the screen upon every animation frame if nothing in the DOM is being changed, and I can't reproduce such behaviour. I know you've probably looked at this, but do you have any <video> or <canvas> or CSS3 transitions on your page? GSAP is only responding to the browsers animation frame event, which doesn't actually necessitate it doing anything to the DOM that would warrant a repaint.

 

Just to be clear that GSAP is 'causing' the page to repaint in your environment, have you tried with a completely empty HTML file as well? i.e.

<!DOCTYPE html>
<html>
<head>
<script type='text/javascript' src='tweenlite.js'></script>
</head>
<body>
</body>
</html>
Link to comment
Share on other sites

Yup, just with that minimal HTML, and only tweenlite.js (no css or easing classes) I'm still seeing a RAF call cause a composite layers event. If I turn on "show paint rectangles" I'm not seeing any actual visual repainting of page resions, but the RAF call is definitely triggering a "composite layers" event.

 

My guess is that a RAF call will automatically cause the new GPU accelerated rendering model to composite layers in my version of Chrome. The fans spinning up on my Macbook Air generally signify something going on with the GPU (its quite under-powered).

 

Here's someone on SO noticing that RAF causes a composite layers:

 

http://stackoverflow.com/questions/12172512/requestanimation-vs-settimeout

 

More about GPU acceleration in Chrome:

 

http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome

 

For my part there was a noticeable system-wide slow down once tweenlite had been hammering RAF/composite layers for a few mins, plus fans kicking in, plus laptop getting quite hot. I guess this might be a temporary issue while Google fine tune the whole GPU accelerated side of things, but seems to me to point towards RAF idling being a sensible default for the time being? Who knows how expertly/inexpertly other browsers will implement GPU accelerated rendering in the short term?

Link to comment
Share on other sites

That is bizarre. And yeah, I bet you're right about it just being a glitch in Chrome that will likely get fixed in an upcoming release. But in any case, we've got this auto-sleep feature baked into the upcoming 1.9.1 release. You can check out a preview by going to this other post: http://forums.greensock.com/topic/6773-requestanimationframe-ticker-keeps-on-going/#entry27923 where I posted a zip. If you wouldn't mind giving that a shot and letting us know how it performs for you, that'd be swell. 

Link to comment
Share on other sites

Yup, see my previous post (about 4 up from this one).

Link to comment
Share on other sites

Sorry - I meant to say I updated the 1.9.1 preview this morning and I was inviting you to try the updated version. It sounds like even the older one was working for you, though, which is good. 

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.
×