TweenMax ticker update issues on mobile

[oholmwood]

I was wondering if anyone could help me with an issue involving TweenMax and Easeljs.

 

We're nearing completion of a game built in EaselJS, and just in the device testing phase. We're finding on some lower end devices, such as the iPhone 4 (iOS7), that whenever the framerate drops from our standard of 24 to around 18 or less, any TweenMax tweens currently running will appear to run at an incredibly low framerate compared to anything else.

 

Other non-tweened movements will continue as you would expect at the framerate drop, but we'll only see as little as three frames in any one TweenMax tween - the start properties, maybe one or two frames somewhere in the middle, and eventually the end properties applied to the object, and that's about it. Very odd. It makes it look like the game is struggling much more than it actually is, as everything not tweened is often running at a reasonable rate.

 

Originally we added an event listener to TweenMax's ticker, telling it to update the canvas on tick but this resulted in a lot of performance issues, as it was trying to update the canvas more often than it needed to. So now we just update the canvas on the EaselJS ticker update.

 

I've since tried setting the TweenMax ticker's fps property to whatever the current easel framerate is, and this is adjusted each frame. This generally improves the animation speed of the tweens quite a bit, but they're still not updating as smoothly as any other animations we have playing on screen during these slightly more intensive moments.

 

The canvas is continuing to update fine, so it seems to be that TweenMax isn't updating the values as frequently as it should be.

 

Does anyone have any idea what might be happening? Is there a relatively easy way to manually update the progress of the tweens, so that the canvas ticker and the TweenMax ticker can be properly synced?

 

Thank you

 

 

 

[GreenSock]

Sorry to hear about the trouble. I'm really curious to investigate because I can't imagine how or why you'd see that kind of discrepancy. By default, GSAP uses requestAnimationFrame to drive all of its updates/ticks. That's a GOOD thing - you don't want updates happening between screen refreshes (that would be utterly wasteful). I'm not sure if EaselJS uses requestAnimationFrame or a setTimeout(). You didn't set TweenLite.ticker.useRAF(false) did you? Even if you did, I don't think that'd give you these results. 

 

Can you whip together a simple codepen example that demonstrates the issue so that we can investigate? I've never heard of something like this before (where FPS appear to drop only for GSAP, but remain much higher for some other thing that's updating on the screen, like EaselJS). Again, I can't even imagine how that'd be possible unless maybe GSAP is running fine but EaselJS isn't rendering the changes in a timely fashion. 

 

Have you tried using an onUpdate on your tween(s) to see if they truly are getting updated less frequently? Maybe add an onUpdate to the GSAP tweens and the EaselJS ones and see if there is any discrepancy. 

[oholmwood]

Thanks for your advice.

 

I've tried to recreate the issue into a simple example, but unfortunately I can't replicate the problem. I'd show you the project but I don't think I'm permitted to do so currently, sadly.

 

I'm not setting the useRAF to false, although when I tried out of curiosity, both easeljs and TweenMax seemed to be in sync, but that they both slowed down to less than a frame per second during the intensive bit!

 

I put in logs on both the onUpdate of a tween that runs throughout and on the update function of easel, and at the most intensive parts, there's definitely a difference in how frequently they're called. Easeljs can get in 8 or more update calls while TweenMax has only reported 1.

 

I think in the meantime I can make some adjustments and convert most of the more important tweens into movements on the easel update function. So it's not necessarily a crucial issue for us, but a bit of an odd one nonetheless. If I figure anything out that may be of use, I'll let you know.

 

Thanks a lot

[GreenSock]

This is very curious - I'd really love to see this happening and get access so that I could poke around. GSAP's update cycle is directly tied to the browser's update cycle (via requestAnimationFrame by default), so this makes absolutely no sense to me how EaselJS could update more frequently than the browser itself (or maybe there's some weird bug in the browser that is preventing it from dispatching requestAnimationFrame accurately, but if that's the case how would EaselJS be able to magically get triggered and update separately?) There's something very strange at play here. I'm not sure I can help much if you can't show us how to replicate the issue. Usually it's really helpful (for me at least) to separate out an isolated, simple test case and build it up from there (getting closer and closer to your production version) until it breaks so that I can see precisely where things break down. Maybe try that? 

[reinierf]

I have the same problem, but only on iPad3. I tried both iOS 6 (6.1.3) and iOS 7 (7.1.1). In both cases a dramatic visual lag occurs. It looks like, during the tween, the canvas is not updated and at the end of the tween the canvas just jumps to the end situation of the tween.

 

The problem does not occur on iPad4 (either iOS 6 or 7).

 

See http://www.innerinterior.com/html/ or

In both cases, a tween should occur on every tap/click. Both use the latest version of createjs.

 

I don't set useRAF to false. I use the latest GSAP version.

 

I've looked at http://forums.greensock.com/topic/6639-tweens-not-working-on-ios6/?p=24455#entry24455 but nothing in that post helped.

[Carl]

Hi reinierf,

 

First, very nice demo.

 

Second, when you say you have the same problem as the original poster are you also claiming that in your app the TweenLite ticker is firing less frequently than the Easel ticker?

 

I put in logs on both the onUpdate of a tween that runs throughout and on the update function of easel, and at the most intensive parts, there's definitely a difference in how frequently they're called. Easeljs can get in 8 or more update calls while TweenMax has only reported 1.

 

 

If so, can you please edit your demo to clearly illustrate this variance?

 

From my own experience and other reports,  canvas performance in older iOS devices is notoriously poor. Without seeing proof to the contrary, I'm likely to believe that this is simply a matter of the hardware not being able to keep up with the frequent renders.

 

The good news is that we are working on a new feature that should allow you to have more control over how the engine responds when CPU spikes occur. Instead of having tweens get forced to their end state, they will play as if only a minor hiccup occurred. Will be interesting to see how this helps your app. 

 

Keep your eyes open for an email announcement in the next few days.

 

-Carl

 

FWIW the demo ran quite well on my iPhone4S iOS6. If I tapped quickly I could experience some hangups, which isn't abnormal. If a tween is scheduled to run for 0.5 seconds and the cpu gets hung up for 1 second, that tween is going to render in its end state on the next tick.

Again, our next update to GSAP will allow you to change this behavior.