Jump to content
GreenSock

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

Greensock slow on mobile devices

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I've been using Greensock animations since its inception with AS and I've been using it for years with the JS version. Its a great library and will continue to use it.So thank you for that. 

 

Regarding desktop browser I have no issues here; however regarding mobile devices. I am seeing animation stuttering on both Android and iOS devices. I want to reiterate that this was also seen on Android devices as well because I know there have been some mention of issues on iOS. However I never saw any real solutions to this stuttering.

 

I wrote a few examples animating with greensock and CSS3. actually the performance was a about the same same. both had some stuttering. The big difference was demonstrated when I introduced CSS3 Transform. This by far outperformed both Greensock and CSS3 Transitions. 

 

So I wanted to know if there was something that I'm missing... I do see that in the 'CSS3 Transitions vs GSAP: Cage Match' it specifically targets Transitions and not Transforms. I am simply looking for the best results to present to my clients. But I'm wondering if for mobile devices CSS3 Transforms are the way to go over Greensock or if there is a technique in Greensock to match the performance that I am overlooking..

 

thank you product and for your time.

Link to comment
Share on other sites

First, please check out this response to a very similar question that I posted within the last 30 minutes: :)

http://forums.greensock.com/topic/7841-css3-plugin-for-hardware-accellerated-devices/#entry29963

 

And just to clarify, when you hear about "CSS transforms", that's just a css property that controls 2D and 3D properties like rotation, scale, skew, and translation (x/y). It's like "CSS background" or "CSS top/left" - those can be edited directly through JavaScript, just like any css value. However, "CSS transitions" are completely different - that's just a browser-based mechanism for changing css values over time. So you could use transitions for transforms or backgroundColor or top or left, etc. So it isn't like you need to choose "CSS transitions" or "CSS transforms" (as if they're mutually exclusive). GSAP can tween CSS transforms, or you can use CSS transitions to animate them. Or you can use CSS animations. They're all valid choices for managing the change over time. GSAP is by FAR the most flexible option, and the API is much more usable in practical real-world scenarios. 

 

I'd love to see a head-to-head example that demonstrates CSS transitions performing significantly better than GSAP. Can you provide a codepen or jsfiddle? 

 

One thing you could try is what I suggested in the other response (linked to above) - just set a small z value which will typically force the browser to push the element to the GPU, thus applying the matrix gets done at the GPU instead of the CPU. This isn't a magic bullet, though, because there are costs involved in pushing things to the GPU (not related to GSAP) and it only has a certain amount of memory, so don't try doing this with 1000 elements all at once. 

 

Again, I'd really like to see a head-to-head example if you can provide one. 

Link to comment
Share on other sites

I'll work on getting the headed to head example but the comparison was not so much GSAP vs CSS transitions (these seem to perform on mobile about the same), the but rather GSAP vs CSS Transforms. Simply moving an object from A to B. Transforms is much smoother than GSAP on Android and Mobile iOS. I admit there are HUGE limitations in using Transforms; however I am only trying to get down to how to output the smoothest performances to the user. I have tried using the Z value fix. but had little affect (however it made a huge difference with Greensock when animating a video container).

Link to comment
Share on other sites

I'm really confused - do you mean "transforms" or "transitions"? Because GSAP does use transforms. Did you know that you can simply use "x" and "y" to have GSAP implement movement using transforms instead of using "left" and "top" properties? For example, let's say you've got an absolutely-positioned element and you want to move it down and over by 100 pixels each direction. Here are two options that give you similar results, but one uses top/left and the other uses x/y transforms:

//uses standard top/left
TweenLite.to(element, 1, {top:100, left:100});

//uses x/y transforms
TweenLite.to(element, 1, {x:100, y:100});

Also keep in mind that by default, GSAP will round pixel values for you because the browser typically must do that anyway, and if we do it internally, it's faster. But you can tell GSAP not to auto round by setting autoRound:false. So I'd be curious if this works well for you: 

TweenLite.to(element, 1, {x:100, y:100, autoRound:false});
Link to comment
Share on other sites

that was the magic bullet! animating x and y instead of top and left offered a much smoother animation. The only difference there is when the animation is run the first time from a browser refresh, there is a jump. but subsequent animations after that were smooth.... I have the following css on the container but still has the jump....

-webkit-transform: translateZ(0.1px);

 

So any insight there would be great. But it certainly seems using x,y yields smoother performance on mobile over top, left.

 

Lastly, if you don't mind. I know the issue of opacity has been raised but using greensock for opacity on mobile is extremely choppy and using ... -webkit-animation is far smoother. Is there a possible workaround to that? 

 

I appreciate you time. thank you.

Link to comment
Share on other sites

Hmmm...I can't imagine why opacity would be radically different (I certainly haven't noticed that). Can you provide a codepen or jsfiddle that clearly shows the difference? I wonder if there's something else in your code that's causing interference somehow.

 

Have you tried that z trick I mentioned that forces the element to the GPU? Like:

//just set z (or any 3D property) once to kick the element to the GPU
TweenLite.set(element, {z:0.1}); 
TweenLite.to(element, 2, {opacity:0.5});
Link to comment
Share on other sites

thank you for that fix... I was using...

-webkit-transform: translateZ(0.1px);

but for some reason this did not yield the same result as yours did.  Anyway, that fix made a huge difference. When doing full page fade-ins there is some stuttering. I likely attribute that to the DOM still loading while fading at the same time; however this stuttering does not occur with CSS3. So because of this I was wondering about the technological differences between using Greensock opacity manipulation and using CSS3 animation.

 

I appreciate your support with these issues cause they make a huge difference in performance and will likely help a lot people out there experiencing the same problems. I have seen similar issues addressed in these forums but have seen little help in actually addressing the issues so thank you for addressing these issues directly. 

Link to comment
Share on other sites

It works :)  you should make a bool to invoke GPU but this will work I recomend documenting this where its more visible this issue wasnt really clear to my team along with the speed difference with x,y verse top and left as well.

 

thanks for your help

Link to comment
Share on other sites

  • 5 months later...

I was having similar performance issues on ios but the "{z:0.1}" trick worked and animations are much smoother now. Though, I did not find any noticeable differences when I switched to use "x,y" properties instead of "left,top" . 

Thanks for the great library and answering our queries!

Link to comment
Share on other sites

Great, thanks for letting us know. By the way, you can now simply set force3D:true and it'll kick in the GPU rendering whenever possible (basically the same as setting z:0.1, but without altering z). Make sure you're using the latest version of GSAP of course. 

Link to comment
Share on other sites

maybe i am confused but i feel like i have read conflicting arguments on animating x and y positions. i seem to recall somewhere else in addition to this form argues that animating a x and y transform should be more efficient than a top/left value, but in the CSSPlugin documentation it says the opposite. which is the more efficient way?

Link to comment
Share on other sites

Well is not a black or white, written in stone kind of stuff.

 

For example if you're aiming to devices with a respectable hardware (iPhone4+, IPad and high-end android) and the amount of elements being animated is not too much, it can boost performance to use x/y with force3D:true instead of top/left, like that those elements are passed to the GPU. Of course desktop/laptops with better GPUs will support more elements, but it will come a moment when the GPU will be overrun and you'll experience a performance issue, then is better to use top/left.

 

Also keep in mind what you're animating, when it comes to PNG images with shadows and alpha channels the browsers just go berserk no matter what properties you animate and if you pass it to the GPU or not.

 

As you can see is a big grey area and the judgement must be done for every project based on what you're seeing with every particular animation.

 

Rodrigo.

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