Jump to content
GreenSock

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

GSAP on iPad

Recommended Posts

I made an interactive learning site that relies entirely on GSAP (HTML 5) for its animations.  Generally, all the animations are quite smooth on Chrome or Firefox, but when I try it on my iPad, they skip sometimes.  It doesn't look bad on the iPad, but it skips and misses parts of some animations.  I know this is a more general question, but is this poorer performance on the iPad normal, or is there anything I can do?  (FYI, I am a science teacher.  I am band new to coding.  I just recently taught myself JS and CSS.)  Thanks!

 

BTW, the site is temporarily at:

 

http://ketzbook.com/chem/elementsymbols/elementsymbolmatch.html

 

  • Like 1
Link to comment
Share on other sites

Hi,

 

Cool game!! it seems that you did an excellent job teaching yourself JS, great job!!

 

For what I saw in your code in some GSAP instances you're using top and left, try replacing them with y and x in order to use hardware acceleration, that might improve performance.

 

Also a question, is always the same part of the animation that is skipping?, is the same type of animation (the fade in/out animations of the symbols for example)?

 

Perhaps you could play with lagSmoothing and see if a smaller threshold can improve performance, but you'll have to see how that affects your timer function (I believe you're using a setInterval for that):

 

http://greensock.com/gsap-1-12-0

 

Give that a try and let us know how it works.

 

Happy Tweening!!

  • Like 2
Link to comment
Share on other sites

thanks!  I'll try the lagSmoothing out.  Yes, I'm using setInterval for the timer, so lagSmoothing shouldn't affect it, right?

I didn't know that x and y work faster than top and left.  Can I simply substitute x for left and y for top, or do I need to adjust the values too?

I think the lag/skipping was the worst at the beginning and especially at the end when changing screens.  Fade didn't cause problems, but when I was changing multiple things (i.e. the size and position of one thing and the position of another at the same time) something skipped.

Link to comment
Share on other sites

Hi,

 

Using X and Y are normally 0 when the elements are first rendered on the screen and for what I saw on your game, most elements have an absolute position, so it shouldn't be any difference. Although the best way to know is testing and testing ;).

 

The lagSmoothing parameter shouldn't affect the timer, since it works in a different areas so to speak, but keep in mind that with lagSmoothing your animations will last as long as they are intended. For example if the animation has to last 0.5 seconds, and when the animation is on the 0.2 seconds mark, the CPU chokes for 0.5 seconds, your animation will restart after the CPU gets un-choked and the missing 0.5 seconds of the animation will complete. During those 0.5 seconds that the CPU gets too busy the timer will still be running, so basically that will mean that the user will have less time. Although the main problems seem to be happening when the timer hasn't started or is already done, but you'll have to play with it and see what happens.

 

Another option would be to store the animations that are giving you trouble and take them to the end and then back to the beginning in order to force the rendering of the values, that could save some CPU cycles and speed things up, like this:

var t1 = TweenLite.to(element1, 1, {vars}),
    t2 = TweenLite.to(element2, 1, {vars});

t1.progress(1).progress(0);

t2.progress(1).progress(0);

Give that a try and let us know how it goes.

  • Like 1
Link to comment
Share on other sites

Thanks for your help!  I think I will try the other options before I try lagSmothing.  I'll look into the progress() method you mentioned above, as I am unfamiliar with that.  It looks like changing over to x and y will take a bit of adjusting more than just a simple switch, so it might be a while before I have the result.  Back to my day job...  ;)

Link to comment
Share on other sites

What if I use force3D:true for my problem animations instead of switching to x and y.  Would that accomplish the same thing?

Link to comment
Share on other sites

Hi,

 

As far as I can see no, because you also are tweening scales and other transform properties and GSAP has an auto force3D feature since version 1.12 that creates a GPU layer for hardware acceleration as soosn as the animation starts and removes it when is completed. The reason for using transforms is because top/left force layout calculations, which consumes CPU cycles, which ultimately keeps the CPU too busy generating the animation hiccups you're describing. Hardware acceleration it's already there so force3D shouldn't make any difference.

Link to comment
Share on other sites

okay, that makes sense.  I checked again, the skipping only happens when there are multiple translations using left and top and size changes (height and width).  Is it okay to animate height and width, or is there something better to use for that?

Link to comment
Share on other sites

Nope, the only alternative would be to use scales or clip, but using scales you'll have to hide the content of the element because it'll look distorted.

 

Here's a demo of the GreenSock collection using clip:

 

See the Pen KmLjr by GreenSock (@GreenSock) on CodePen

  • Like 2
Link to comment
Share on other sites

Changing from top to y on my problem animations did not seem to help.  I am going to give clip a try; if I had known about it, I would have used clip to start with...that would have been a lot easier that changing height and top simultaneously.  I may also need to look into other parts of my code like streamlining my eventlisters.  A lot is going on at the beginning and end, and that may just be too much for the weaker iPad CPU.

Link to comment
Share on other sites

Using x/y instead of top/left will engage the GPU.  This is better most of the time, but not every time.  Engaging the CPU allows for smoother, subpixel rendering.  And you'll experience fewer skips and jumps.

 

But also since it uses subpixels it can result in a “blurrier” animation, since the image won't be defined perfectly on a per pixel basis.  

 

My typical approach is to use x/y when tweening something complex (especially something with CSS box shadows or blurs).  And use top/left when tweening something simple with text that needs to stay crisp.  

 

Ketz -- if you can't get the performance to improve, you might want to try leaving off any box-shadows on tweened elements.  That'll take a load off the processor.

  • Like 2
Link to comment
Share on other sites

MindGamer, The blurry animations usually happens due to browser bugs and how they handle 3d transforms, especially in Chrome with text. But they can be corrected by using a combination of other CSS properties like perspective, transformPerspective, transformStyle:preserve-3d, etc. Also adding slight rotations, translateZ (z), and or skewX  can help with these blurry browser bugs. Using left  and top  will aways force the browser with expensive layout  and paint  operations. That is why x and y are always better than top  and left. You will get better perfomance with no relayout and relpaint cost that is associated with using top and left. ;)

 

Especially when scaling in webkit based browsers. Sometimes you need to set the initial scale less than a zoom factor of 1, and then have your actual width and height a little larger for the zoom factor less than 1. Chrome keeps fixing and then breaking their text anti-aliasing of transformed elements, an on going webkit bug. So it is always in flux.

 

But IMHO, Im of the mind set that set if the browser supports 3d transforms, then to never let the browser dictate to me when i should or shouldnt use something due to their buggy implementation. Especially when to use 2d or 3d transforms, since various CSS properties can workaround these browser rendering bugs.

Like Rodrigo says... If you have the will, you'll find the way. But you will see as you test that usually adding or removing a CSS property, and/or changing a CSS property value can help you in getting cross browser rendering of 2d and 3d transforms.

 

ketz ..what parts or steps of your learning tool (pretty cool by the way) are skipping, this way we can narrow down where your seeing this on the iPad:

  • what iPad version?
  • what browser on the iPad.. safari or chrome?
  • and what browser version?

Thanks for any additional info? When I have more time I will try and debug your example on the iPad ;)

Link to comment
Share on other sites

First off ketz, great learning game .. i learned alot! :D

I just got done debugging your learning game on iPad and found some things:

Since you have a box-shadow, a gradient, and border-radius on your highest most div #backdrop .. it is causing massive repaints of the whole screen.

Once you follow Rodrigos advice on changing your GSAP code to use x instead of left  and use y instead of top .. you should see a dramatic change in performance, especially on the ipad.

By using top and left your causing the browser to constanly have to relayout and then repaint which is why you are seeing that jank (lost frames) on the iPad.

In your elementsymbolmatch.css  i  see that the browser has to rasterize your text due to the text-shadow you have on your text elements (.elementName, .elementSymbol, etc ..). Which is  a child of a parent that your transforming. I see that it is causing a long rastersize repaint that has to perform 3 paint passes just to render the text in one frame

Layout and painting are very expensive to recalculate. Also try removing box-shadow  and text-shadow  to improve performance. Otherwise the browser will have to constantly repaint .. relayout and then repaint again.

 

Here is also a link that can help you decide which CSS properties trigger layout, paint, and composite

 

http://csstriggers.com/

  • top, right, bottom, left:
    Changing top, right, bottom, left alters the geometry of the element. That means that it may affect the position or size of other elements on the page, both of which require the browser to perform layout operations. Once those layout operations have completed any damaged pixels will need to be painted and the page must then be composited together.
  • text-shadow, box-shadow:
    Changing text-shadow, box-shadow does not trigger any geometry changes, which is good. But since it is a visual property, it will cause painting to occur. Painting is typically a super expensive operation, so you should be cautious. Once any pixels have been painted the page will be composited together.

 

Depending on your meta viewport tag on the page.. You could always just detect if the browser is on mobile  or a tablet  .. than just disable those expensive css properties. This way users on desktop get the full juice ;)

/* to target tablet iPad and iPhone - which primarily use webkit */
@media only screen and (min-device-width: 768px) and (max-device-width: 1024px), 
@media only screen and (max-device-width: 480px) {
  
    #backdrop,
    #backdrop * {
        -webkit-box-shadow: none;
        box-shadow: none;
        -webkit-text-shadow: none;
        text-shadow: none;
    }

    /* .. OR specify each element with box-shadow, text-shadow, gradients .. */

    #backdrop {
         -webkit-box-shadow: none;
         box-shadow: none;         
    }

    .elementName,
    .elementSymbol,
    #introductionDescription {
         -webkit-text-shadow: none;
         text-shadow: none;
    }

}
I hope this helps :)
  • Like 2
Link to comment
Share on other sites

Thanks everyone, this has been a real learning experience.  I didn't realize that text-shadow and the like used so much juice.  I'll probably remove most of it.

 

The only parts I really noticed the skipping were at the beginning and the end (i.e. when I translate the intro screen out and I use the TV screen effect to turn on the game screen).  I only noticed this on my iPad (Safari), not on my desktop (Chrome, Firefox, IE 9 all ok).

 

I see why box-shadow and text effects would slow things down for animated elements, but why would it matter for #backdrop?  #backdrop doesn't change at all, and you are sure that it is responsible for massive repaints?  If you're sure about that, I will probably replace the #backdrop effects with an image instead.  Images should should be easier on the processor, right?  I guess I just got a little too carried away with CSS effects ;)

Link to comment
Share on other sites

When I was debugging your game today, that's where I saw the most layout and paints, when the page loaded. But that can be fixed rather easy by doing a several little things.

 

You could modify loaded assets, organizing the order of your js files, use tinypng.com to compress jpg and png images, merge and minifying JS and CSS files, animate x and y instead of top and left so you don't trigger more layout, waiting for the DOM and window to be loaded before animating, reducing markup, etc.

 

Just alot of little things that can help your page load faster, and help. You might be able to keep the CSS shadows depending on when you switch to animating x and y.

 

That just might do the trick, allowing you to not have to disable shadows for mobile and tablets :)

  • Like 1
Link to comment
Share on other sites

So far:

switched from top to y on problem translations

switched title and #stage to images

used tinypng on all png pics

 

There is now a noticeable improvement.  I can still see some lag at the beginning, but it is looking better.  I'll try out the "clip" for my TV screen effect and replace the other translations with x, y.  I might also change the button event listener, as it seems that the touch screen click lag may be effecting the animations too.  Thanks for your help!

  • Like 3
Link to comment
Share on other sites

No worries.. we are glad to help :)

Link to comment
Share on other sites

Okay, two more questions:

 

1) Suppose I animate a simple div with only text and no special CSS effects.  However, the parent or a sibling of the div has things like text-shadow, box-shadow, and gradient.  What does your browser need to do?  Does it still need to do the layout, paint, and composite operations?

 

2) How can we compare the browser performance of a translation for the following things:

     a) a box with text, background color, curved border, text-shadow, box-shadow, and gradient

     B) a box with only text, background color, and curved border

     c) an image with the same contents as (a)

Link to comment
Share on other sites

Hello ketz,

 

Regarding the first question:

  • Yes It would, due to it's parent having to be rendered again first, and then its children going cycling down the DOM tree

Regarding the second question:

  • You could just setup a page with all three separate.. and use the browser dev tools to see which one loads faster. An image would work depending if the image was small and optimized. But more than not regular html would be faster. But you would have to test depending on the weight of css styles on your HTML, compared to the image.

But I believe your main issue was animating using top and left. When animating its best to use x and y. If you have any remaining tweens animating top and left. I would change them to x and y.

 

It is perfectly fine for you to first position your elements using top and left in your style sheet. So you set your initial position of your elements, but then when you animate use x and y instead of left and top. All you should have to do is just change left to x and y to top in your tweens.. leaving your initial top and left of your elements in your style sheet. Then you shouldn't have to worry about box-shadow and text-shadow, which are expensive to render. But the more expensive operation is animating multiple DOM elements with left and top.

 

The best thing to do after switching your tween to x and y .. is to just test, test, test. Try removing css properties in your style sheet and then test , and repeat the process untill you are satisfied with the performance :)

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