Very slow animations on iPad 2, how to optimize?

[Mich]

Hi,
i'm working on a site using SuperScrollorama. My site has 6 big png-24 + alpha that are animated like this:

  // slide0 
     controller.addTween(
        '#slide0',
        (new TimelineLite())
           .append([
              TweenMax.fromTo( $('#sprite1'), 1, {css:{left:50+"%", top:170, scaleX:1.0, scaleY:1.0}}, {css:{left:30+"%", top:150, scaleX:1.2, scaleY:1.2}, ease:Quad.easeInOut}),
              TweenMax.fromTo( $('#sprite2'), 2, {css:{left:80+"%", top:230, scaleX:1.0, scaleY:1.0}}, {css:{left:50+"%", top:230, scaleX:1.1, scaleY:1.1}, ease:Quad.easeInOut})
           ]),
         0, // scroll duration of tween
         0
     );

On my computer, it's fast and fluid (perfect on IE 11 and Firefox, slower on Google Chrome).

But on my iPad 2, it's a disaster : very very slow !! I tried with png 8, 256 colors + transparency. It's a little bit better. I tried the Superscrollorama on the iPad, and i noticed that's it's not very smooth.

 

So my questions :
- is it a processor problem / graphic card problem?

- how to get perfect smoothness on iPad? Does anyone has a website example that i can test?

 

Thanks for any help.

[Rodrigo]

Hi Mich,

 

Have you tried optimizing the PNG files, changing the file type in photoshop to 8 bit png is not always enough.

 

Just a few days ago this post was published on Creative Bloq, take a look at it:

http://www.creativebloq.com/design/image-compression-tools-1132865

 

For me this is about the fact that you're using PNG's with alpha channels, basically you're asking too much for that hardware (even the iPad). Try optimizing the files and add force3D:true to your tweens, in order to create GPU layers in order to take some load of the CPU, but at the end this could be a rendering issue, just a limitation of the device's hardware.

// slide0 
     controller.addTween(
        '#slide0',
        (new TimelineLite())
           .append([
              TweenMax.fromTo( $('#sprite1'), 1, {css:{left:50+"%", top:170, scaleX:1.0, scaleY:1.0}}, {css:{left:30+"%", top:150, scaleX:1.2, scaleY:1.2}, force3D:true, ease:Quad.easeInOut}),
              TweenMax.fromTo( $('#sprite2'), 2, {css:{left:80+"%", top:230, scaleX:1.0, scaleY:1.0}}, {css:{left:50+"%", top:230, scaleX:1.1, scaleY:1.1}, force3D:true, ease:Quad.easeInOut})
           ]),
         0, // scroll duration of tween
         0
     ); 

Rodrigo.

[Mich]

Thanks Rodrigo.
I just tested the force3d:true, that doesn't change anything on my ipad.
When removing all tween animations, and just leaving the ScrollTop animation (vertical scroll between my 4 contents), the iPad is very slow too, so the problem seems to be the png (i added the -webkit-transform: translate3d(0,0,0); to all child of the container but nothing changes).
Thanks for your optimisation link, i'm reading it at the moment and will come back with others news.

[Jonathan]

Hello Mich..

 

What IOS version is running on your iPad 2 ?

[Mich]

Hi Jonathan, ios 7

[Carl]

In addition to the great advice previously offered, I would suggest an additional test of replacing all your pngs with jpgs. I understand you probably need the alpha in your project but it will be interesting to know exactly how great a strain the alpha rendering is.

 

---

 

 

Although its of little help, I've heard many times anecdotally that iOS7 is quite problematic on older hardware. Personally I've resisted upgrading my iphone4S due to some of the horror stories I've heard.  

[GreenSock]

For the record, I'm pretty sure that the whole PNG-vs-JPG thing would only impact the decoding of the image upon load, not so much the runtime/rendering performance. Think of it like different ways of packaging the pixels - at the end of the day, the browser still has to paint the same number of pixels to the screen once they're all in memory. The biggest issue is almost always the quantity of pixels that you're asking the browser to redraw on each "tick". 

 

Scrolling is a particularly difficult thing for devices to do (performance-wise) which is why iOS completely freezes all animations while you're scrolling (it's trying to throw all of its limited resources at keeping the scroll as smooth as possible). When you're not scrolling, the browser only has to worry about the actual visible pixels in the viewport, but when you scroll it has to look BEYOND the visible area to render the upcoming content that's being scrolled into view. That's tough for a device with such a weak processor. 

 

And yes, iOS7 Safari has some pretty serious performance degradations, one of which I blogged about here: http://www.greensock.com/ios7/

 

I'm pretty confident that the performance problems have nothing to do with GSAP (I guess that's good news and bad news, depending how you look at it)