Jump to content
GreenSock

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

Animations are very choppy and slow in iOS

Recommended Posts

I am using GSAP along with a ScrollMagic plugin to time my animations using the user scroll. Everything works great on desktop, animations are smooth and look nice. But when I load the site on tablet and mobile issues start to show up.

 

I have an iPad and a Galaxy S4, and the galaxy is performing much better than the iPad is. On scroll for the Galaxy there is a short jump at the start, past that the animations are a bit slow but work in general. When it comes to the iPad, the animations are nonexistant... on scroll everything locks up and moves for the scroll, then it seems to reload and moves everything to where they should be instantly. There is no tweening or easing happening and creates a very poor experience on tablet.

 

Im looking for a way to improve performence on mobile / tablet and allow tweening and easing to happen at all on tablet. Thank you

Link to comment
Share on other sites

Let me guess: you're on an outdated version of iOS? It has nothing to do with GSAP - it's just that Safari on iOS would completely stop all animations during the scroll. Literally, think of it as if it took a screen capture of the pixels as they were when you pressed your finger down, and then it just moves those [locked] pixels for the scroll, and then when you release, the page comes to life again. In more recent versions of iOS, Apple fixed that. 

 

Again, the same thing would happen regardless of the animation engine (even CSS animations). It was a limitation of the browser itself. The only solution I'm aware of is to literally hijack the scrolling and manage it manually. Some people have used our Draggable tool for exactly that and they said it worked great on iOS. I'm not entirely sure how that'd integrate with ScrollMagic though. 

 

By the way, make sure you're using transforms for movement on your tweens rather than top/left. In other words, use x, y, rotation, scaleX, scaleY, etc. because those are hardware accelerated and much easier on mobile devices. Also make sure you're using the latest version of GSAP. 

  • Like 1
Link to comment
Share on other sites

I updated my iOS and the issue still remains in both chrome and safari on the tablet. Ill look more into the browsers to make sure theyre up to date but they I dont see any update prompts. But yes the screen capture analogy is exactly what is happening, it scrolls the screen cap then everything jumps to where it would have animated to.

 

What do you mean by hijacking the scroll? Im not sure if you have used scroll magic before, this is only my second time using it so im not an expert on the library. It could also have something to do with the amount of animations going on. here is the current state of the project im working on: http://snowtaps.com/ 

 

Im moving quite a few pngs around the page. I started changing my top/lefts to x/y's and havent tested it on mobile yet, but my x and y values are getting ridiculously high. it takes x:1000% for something to go to the right edge of the screen. Am I doing something wrong? im using tweenMax.fromTo in a Timeline.Max for the scenes. Let me know your thoughts, it seems odd how high the values are

Link to comment
Share on other sites

You should DEFINITELY switch to x/y from top/left - now that I've seen what you're doing, that's imperative because you're putting a ton of pressure on the compositor with all the items flying around the screen and the fact that it basically requires the entire screen gets repainted 60 times per second (rather than keeping the "dirty" area on each frame as small as possible). To be clear, the biggest bottleneck BY FAR here is graphics rendering which is purely a browser function (GSAP has absolutely no control over that). In other words, GSAP may use 0.1% of the total CPU load to do its thing, but then the browser has to paint all the pixels in their new spots which may account for 99.9% of the load. So no matter how blazingly fast GSAP is, it may not make much of a dent in what you're doing. 

 

If you use x/y, at least you'll force the elements to be layerized independently which should help ease the load on the compositor, particularly on mobile. 

 

As for the percentages, keep in mind that those are relative to the element itself, not its container. So if you have a 10px square, and you animate to x:100%, it'd move only 10px. Is there a reason you're doing percentage-based animation rather than pixel-based animation? Just curious. 

 

When I said hijacking the scroll, I mean literally intercepting the scroll event on the window and calling preventDefault() on it so that there's no native scrolling, and then manually setting the scrollTop or scrollLeft values via JavaScript to do the scrolling. That's what Draggable does when you set it to type:"scroll". That being said, I suspect that it won't entirely solve your problem because of the amount of strain you're putting on the compositor and scrolling puts an even bigger strain on it because there are new pixels being introduced along an entire side of the screen. That's why Apple used to halt animations during scroll - I'm pretty sure they were trying to keep people from getting totally frustrated when the frame rate dropped dramatically as they had to do all the new compositing tasks during the scroll. It was just too much for the devices to handle. Again, this has nothing to do with GSAP. 

 

Does that clear things up at all?

  • Like 1
Link to comment
Share on other sites

Thank you, this is all very helpful. This is only my second project using greensock, but its just wonderful.

 

As for the percents vs pixels, ive found that in my experience with sooo many different monitor sizes these days, percents tend to be more responsive. But i have never used x and y based positioning before so I was unaware of the fact the percents were relative to element size. Would using pixel based animations be more beneficial? Im leaning towards using pixels after the percents getting out of hand at sometimes.

Link to comment
Share on other sites

It really just depends on whether or not your particular layout is responsive and NEEDS percentage-based values. Most don't. There's not a "right' or "wrong" answer - it just depends on your layout.

 

Glad you're enjoying GSAP thus far! Usually people tell us they like it even more as they go deeper and deeper. So if you've only done 2 projects with it thus far, you're probably gonna find more to love as you gain experience, especially now that you're past the biggest learning curve. Happy tweening!

Link to comment
Share on other sites

This project must be responsive to mobile and tablet, and the fluid nature of many elements moving around the page makes me think I should use percentages. But with some of the smaller elements being animated 1000% at times its getting a little crazy and makes me want to change to pixels.

 

If it were you making this page responsive: http://snowtaps.com/ which would you suggest?

Link to comment
Share on other sites

But yea, greensock will most likely be in all my projects in the future. #tweeningForLife

Link to comment
Share on other sites

The only reason percentages would help is if you're using media queries and you're literally changing the size of the moving elements themselves. If you're not, then px-based values will work exactly like the percentage-based ones. 

 

Unfortunately, I don't really have time to analyze all your code and CSS in that link and provide specific advice. I wish I did - I'm just swamped and we try to stay focused here on very specific GSAP questions. Let us know if you need any other help. Happy tweening!

  • Like 1
Link to comment
Share on other sites

I have same problem. But i changed all CSS elements with opacity less than 1 and the performance was better. Looks like when you render elements with less opacity consume a lot of cpu

Link to comment
Share on other sites

I have same problem. But i changed all CSS elements with opacity less than 1 and the performance was better. Looks like when you render elements with less opacity consume a lot of cpu

 

Good point. I experienced the same issue. If opacity is causing problems, and depending on your content, sometimes it might be better to use a png instead. You can still animate opacity with a png by using the Stepped Ease with a sprite sheet.

  • Like 1
Link to comment
Share on other sites

It may also help to set force3D:true so that it gets its own compositor layer. Opacity and transforms can get a big boost from that. 

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