Tween in mobile device could sometime break by some browser events

[George]

I'm using GSAP for HTML5 games on mobile devices, it works great so far. One thing I noticed though, when some browser events happen, such as rotating devices which would force screen resizing, or change to fullscreen mode, GSAP tween likely stop working and break the game logic.

 

I did some search someone had similar issue (that case not on mobile though), the workaround was to set a timeout instead of using onComplete function. I'm not quite sure whether GSAP would plan to investigate these issue or not.

 

Thanks

[Jonathan]

Hello George, and welcoem to the GreenSock Forum!

 

You could try to use JavaScript to check if the orientation has changed in the browser.. Then when it detects the change.. you can kill your tweens and restart them... or maybe even pause() them and then resume() them after the orientation change.

 

Here is a nice article on detecting the orientation change in javascript:

 

http://fettblog.eu/blog/2012/04/16/robust-but-hacky-way-of-portraitlandscape-detection/

 

And then you could put the different GSAP methods to kill the tween or timeline when orientation change is triggered and then restart the animation.

// checks landscape and portrait change on mobile
window.onorientationchange = function() {
  switch(window.orientation) {
    case 0:

        // do portrait stuff
        // kill tweens and restart
        // or pause() and resume()
     
        break;
    case 90:

        // do landscape stuff
        // kill tweens and restart
        // or pause() and resume()

        break;
    case -90:

        // do landscape stuff
        // kill tweens and restart
        // or pause() and resume()

        break;
    case 180:

        // do portrait stuff upside-down
        // kill tweens and restart
        // or pause() and resume()

        break;
  }
}

Different kill methods in GSAP:

 

kill()

 

Kills the animation entirely or in part depending on the parameters.

 

http://api.greensock.com/js/com/greensock/core/Animation.html#kill()

_________________________________________________________________

 

killAll()

 

Kills all tweens and/or delayedCalls/callbacks, and/or timelines, optionally forcing them to completion first.

 

http://api.greensock.com/js/com/greensock/TweenMax.html#killAll()

_________________________________________________________________

 

killChildTweensOf()

 

Kills all tweens of the children of a particular DOM element, optionally forcing them to completion first.

 

http://api.greensock.com/js/com/greensock/TweenMax.html#killChildTweensOf()

_________________________________________________________________

 

killTweensOf()

 

Kills all the tweens (or specific tweening properties) of a particular object or the delayedCalls to a particular function.

 

http://api.greensock.com/js/com/greensock/TweenMax.html#killTweensOf()

_________________________________________________________________

 

You could use any of the above GSAP methods to kill the animation in part or entirely depending on the parameters and what method you use.

 

To better help you.. Here is a video tut by GreenSock on How to create a codepen demo example.

 

I hope this helps!

[Rodrigo]

Hi George,

 

To complement Jonathan's answer, you could attach an onUpdate callback with a console log or something similar in a particular GSAP instance and see if the callback keeps triggering.

 

Question. Do you have any GSAP instances being triggered during the orientation change event?. If so check that they don't collide with another instance already running before the orientation change, that will cause the overwrite manager to give control of the instance's target to the latest instance created, that'll be the orientation change.

 

Finally if it's possible could you please provide a codepen with a reduced sample?, in order to take a better look at what could be causing this.

 

Rodrigo.

[GreenSock]

I'd echo what Rodrigo says - I suspect you're creating some other conflicting tweens that are overwriting the old ones, thus their onComplete doesn't fire. I cannot imagine any other reason why an onComplete wouldn't fire. It absolutely, positively should fire unless you pause() it or overwrite it with another tween. A simple codepen would go a long way to seeing what's going on. 

[George]

Thanks for replies. I'll take a look and investigate more later when have time.

 

The problem happened only several times (still several games under development so didn't test too much though) when testing on iphone/android tablet on first touch event. As workaround the first touch would trigger sound for iOS, in Android it would trigger fullscreen mode. Each time this kind of issue happen the game would stop, and it's a moment the game running one or two tweenlite instances (one view tween in another tween out) while at the same time the browser likely interrupt/pause the regular Javascript process, for example, playing the first sound at the first touch in iOS Safari would take a short moment browser 'freeze', touch canvas to switch to full screen mode would 'freeze' the android chrome browser a little more second (all game graphics would be resized to fit for larger screen size at the moment which would cost some Javascript time as well). So I guess this would possibly stop the tweenlite instances because of waiting too long. Tweenlite works quite well if not in these special situations. I'll try to get more debug information later to see where the real problem is.

[GreenSock]

GSAP was specifically designed so that it isn't dependent on a specific frame rate, and it dynamically adjusts to hiccups in the device's CPU processing, etc.

 

For example, let's say you've got a 1-second tween that's almost done (maybe it's at 0.95 seconds) and then the CPU gets bombarded with some major processing task so that it doesn't fire off another requestAnimationFrame event (or setTimeout()) for 2 entire seconds. That's fine - GSAP will render that 1-second tween at its end state and fire the onComplete at that point (on the next render). 

 

There is absolutely NO reason I can think of that a tween would simply stop working or refuse to fire its onComplete unless you either pause() or kill() it or it gets overwritten by another tween of the same properties. None. 

 

One of the biggest reasons so many businesses rely on GSAP every day is because it "just works". If tweens randomly just stopped working, I can assure you that we'd hear about it from our customers, and it'd be pretty upsetting (for us and our customers). That's not to say that there can't possibly be a bug somewhere. There certainly could. We've squashed plenty of them over the years. I'm simply saying that we've put a ton of time into engineering a system that scales well and doesn't fall apart when the device has to think about something else for a while. I'm very curious to see an example of the behavior so that we can identify if there's a bug in GSAP or if it's just a logic flaw in the way you're running the tweens (such that they're getting overwritten). 

[George]

The debug console logs shows TweenLite works everything correctly during my testing tonight with Android tablet when changing fullscreen mode. Switching to fullscreen mode do breaking image loading or off-screen cache so it failed to draw mysteriously, making the game as if 'freeze', even those image data do exist and 'drawing' on canvas.

 

Thanks again for helps. Thanks Jack for making such a great library for AS3 and Javascript.