Jump to content
GreenSock

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

(iBooks / WebKit) Timelines freezing after a couple of minutes

Recommended Posts

Hi all,

 

first of all congrats on the great animation engine. 

 

I am using GreenSock, mainly TimelineMax and TweenMax for timing and tweening positions, rotations etc. of my WebGL / ThreeJS scene objects.

 

The resulting format is always an interactive (Apple) iBook for children - basically a compressed website that runs with a WebKit standard similar to the one used in Safari Mobile.

 

Performance was never a real issue until a colleague recently discovered that certain animations freeze or behave different (jumpy, stuttery) after running for several minutes (about 10-15 minutes dependent on the device) while others still run smoothly.

 

It occurs only on the mobile device and only on generations < iPhone 6. 

What helps is to throttle the TweenMax ticker fps down to 30, but of course this doesn't look as smooth.

I also tried playing with the lagSmoothing - with no success.

 

Do you have an idea where these freezes come from? Since they occur only after a certain amount of time.. could it be that the JS execution stack suddenly becomes too big because the device isn't really capable of doing 60fps? Turning RAF on and of also didn't change much.

 

Thanks for any hints or input.

 

 

Link to comment
Share on other sites

Hm, it's really tough to diagnose blind, but here are a few random thoughts:

  1. If it's just a once-in-a-while pause (rather than a progressive slowdown), that sounds to me like a GC (garbage collection) issue. That's not controlled by GSAP at all - it's a browser thing that happens whenever it decides. The only way to avoid this is usually to just try to minimize the amount of objects you're creating. But honestly, it might just be an oddity in how the browser is deciding when to run things and you may be powerless to do much about it. 
  2. If it's a progressive slowdown, that sounds to me like a logic issue in the code where maybe you've got, for example, a function that creates two tweens that both call that same function in their onComplete, thus there becomes 4 tweens, then 8, then 16, etc. forever. I've seen people do that accidentally on occasion and of course it reaches a point where the CPU can't keep up. Again, very tough to diagnose blind. 
  3. Another thing to check is if you're constantly adding elements to the DOM or something. Perhaps it's getting more and more complex to where the browser starts choking. 

Good luck tracking down the issue, and please let us know what you find. 

  • Like 2
Link to comment
Share on other sites

Thank you for the quick reply. 

 

Regarding 2. and 3. - I had these concerns too, but shouldn't these have a remarkable impact when profiling the page in Google Developer Tools or Safari Web Inspector? I had a closer look at the JS Heap and GPU memory over time and there is no real cumulative growth. (Have a look at the screenshot below)

 

http://bit.ly/2gM9Ab1

Link to comment
Share on other sites

To me, it looks like there's some leaking going on. You say there's no cumulative growth in the JS heap but there is a seesaw pattern to that and the teeth get longer and longer as time passes.

 

As Jack himself said, it's very hard to troubleshoot blind, though. There seems to be a very definite point in time where the JS really hits a snag and things just get complicated there. See if you can zoom down where the seesaw pattern gets longer and look check what methods kicked in at that very moment.

  • Like 1
Link to comment
Share on other sites

Hello TigerCreate,

 

This would be really hard to know whats going on without seeing and testing your code live, and in context. It could just be a missing css property or the cause of some logic.

  • What CSS properties are you animating?
  • What values are you animating from or to?
  • How are you animating them?

There could be layout thrashing going on. But without a code example it will be impossible to even know whether it is CSS, JS, or DOM related.

 

Or if it is a known browser bug that affects iOS devices.

 

A limited codepen demo example would help greatly in testing your code live.

 

 

Any additional info and code will be greatly appreciated to help us help you :)

Link to comment
Share on other sites

Hello TigerCreate,

 

This would be really hard to know whats going on without seeing and testing your code live, and in context. It could just be a missing css property or the cause of some logic.

  • What CSS properties are you animating?
  • What values are you animating from or to?
  • How are you animating them?

There could be layout thrashing going on. But without a code example it will be impossible to even know whether it is CSS, JS, or DOM related.

 

Or if it is a known browser bug that affects iOS devices.

 

A limited codepen demo example would help greatly in testing your code live.

 

 

Any additional info and code will be greatly appreciated to help us help you :)

 

 

Hello Jonathan,

 

as already written in my problem description, I'm using WebGL rendering and not DOM / CSS (except the rudimentary html scaffold).

And yes, it only occurs on iOS mobile devices.

 

I'd love to share code with you but I can't narrow down the problem to a slim POC since it only happens in complex scenes and only on the device.

And even then it's not reliably reproducible.. 

Link to comment
Share on other sites

To me, it looks like there's some leaking going on. You say there's no cumulative growth in the JS heap but there is a seesaw pattern to that and the teeth get longer and longer as time passes.

 

As Jack himself said, it's very hard to troubleshoot blind, though. There seems to be a very definite point in time where the JS really hits a snag and things just get complicated there. See if you can zoom down where the seesaw pattern gets longer and look check what methods kicked in at that very moment.

 

Thank you Dipscom,

 

you were right about the leaking. I fixed it with the help of heap snapshot comparison, unfortunately the freezes are still there.

Here's how the curve looks now:

http://bit.ly/2hy3WJd

 

Maybe an idea why throttling the fps to 30 fixes the issue?

Link to comment
Share on other sites

Throttling the fps helps probably because the browser then has twice as much time to calculate whatever it needs to before showing the frame.

 

Sometimes higher fps is detrimental to your animation. If you have too much going on, it will fail some of the calculations, dropping frames, janking a bit, if you give the browser a bit more time (less frames to render per second), then it may stop struggling and will be able to do all its work in the time given so, all frames are rendered and show in time thus, the experience feels better.

 

Still looking at your snapshot, something just kicks in at 30000ms and a pattern emerges. What is it that is happening there to create such intense and constant heaps? I'd narrow down around that moment in time and see what fires there that causes such pattern.

 

We know bugs in computers these days are all caused by us, it's just a matter of isolating the components and reviewing them to spot where it is. It's not like in the old, old days where a real bug could be the cause of an application error.

  • Like 1
Link to comment
Share on other sites

Sometimes higher fps is detrimental to your animation. If you have too much going on, it will fail some of the calculations, dropping frames, janking a bit

 

But does this explain why only certain timelines freeze while others still are running and being rendered smoothly?

That's why I asked this on the GSAP board - I was hoping that these (maybe) timeline related hick ups, call stack size exceedance or whatever it really is can be narrowed down by monitoring internal GSAP parameters that can be helpful in developing a debug strategy.

 

Again sorry the blind diagnosing, it's the same situation for me since the problems only occur on certain device generations and only in iBooks (not in mobile Safari). There is no real time debug information such as a js console or any profiling tools for that, at least none that I'm aware of.

 

What is it that is happening there to create such intense and constant heaps? I'd narrow down around that moment in time and see what fires there that causes such pattern.

 

What is unusual with the pattern.. the heap size? It kicks in at a state where all start animations are finished (around 30000ms) and the scene remains with some endless loops like clouds flying by and some hint icons occasionally popping up. 

Link to comment
Share on other sites

But does this explain why only certain timelines freeze while others still are running and being rendered smoothly?

That's why I asked this on the GSAP board - I was hoping that these (maybe) timeline related hick ups, call stack size exceedance or whatever it really is can be narrowed down by monitoring internal GSAP parameters that can be helpful in developing a debug strategy.

 

Again sorry the blind diagnosing, it's the same situation for me since the problems only occur on certain device generations and only in iBooks (not in mobile Safari). There is no real time debug information such as a js console or any profiling tools for that, at least none that I'm aware of.

 

No, it doesn't exactly. It's just a general hypothesis for the most generic cause of improvement from reduced frame rate.

 

We're all happy to help as much as we can. I hope you also appreciate that there is only so much we can do without seeing the application running and the code in context. We also understand that not everyone can share what they are working on. So, blind we march onwards.

 

 

What is unusual with the pattern.. the heap size? It kicks in at a state where all start animations are finished (around 30000ms) and the scene remains with some endless loops like clouds flying by and some hint icons occasionally popping up. 

 

What makes me suspicious of that is that it jumps up around the 30000ms mark and stays in that cyclical pattern. Even more now that you say the animations are finished and the scene stays idle with some looping cycles and the occasional hints popping up.

 

There's not much left to do other than trial and repetition to see if you can isolate the issue. I'd start there, listing all the animations that stop and should not play, going over the ones that are looping and checking that they're not calling other methods or that they're creating phantom repeats. I'd start disabling other animations that are not freezing to see if stops the freezing, i'd turn off the hints to see if helps and so on.

 

Ultimately, it could be something on the hardware itself, a power saving mode that kicks in if you leave it alone for a while... Or on the iBooks itself.

  • Like 3
Link to comment
Share on other sites

We're all happy to help as much as we can. I hope you also appreciate that there is only so much we can do without seeing the application running and the code in context. 

 

Appreciate every bit my friend and the comments were helpful to take a new perspective towards the problem.

I have to admit it's also not the best issue to expose in a forum since it's somehow linked with an increase in complexity which makes it more difficult to reproduce and isolate the problem.

Therefore a special thanks for your courage in onmarching blindly.

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