Jump to content
Search Community

bad performance tweening dom elements on Android.

boy2k test
Moderator Tag

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

Hi all,

we are experiencing really bad performance tweening dom elements when running on android devices. The same code runs nice and smooth on iOS so i just wanted to check if there are any tweaks or hacks to get more from android? 


The difference is quite big...

Link to comment
Share on other sites

Hello and welcome to the GreenSock Forum!


GSAP performs really good on Android. Do you have an example via

See the Pen by pen (@pen) on CodePen

or jsfiddle to better see what issues you are having.

  • what version of Android are you seeing this on?
  • what device and model are you seeing this on?

I will be more than happy to help test on Android, so we can see why you are having bad performance.


thx :)

Link to comment
Share on other sites

Hi jon,

Thanks for helping us with this.

The actual code isn't something to easy to put into a fiddle as its part of a dynamic game on a locked down internal network. 


We have lifted out a small section so you can test though. 


Its a simple tween to open a panel, super smooth on iOS but nasty on android 4.1 (galaxy tab 2) and nasty on galaxy note also.


Link to comment
Share on other sites

Thanks for the example...

Looks like maybe some pixel-snapping might be happening due to sub-pixels of the computed CSS bottom property in the style sheet for #betPlacer

Example: http://jsfiddle.net/m5ycR/11/

there are a number of things you can do..

var $betPlacer = $('#betPlacer'),
    betPlacerH = $betPlacer.height(),
    betSlipH = $betPlacer.children('.bet__slip').height(),
    betNewHeight = betPlacerH-betSlipH;

// set #betPlacer bottom
TweenLite.set($betPlacer ,{"bottom":"-"+betNewHeight+"px"});

$('#betOptions, #betPlacer .bet__slip').on("mouseup", function () {

    TweenLite.to($betPlacer, 0.35, { css:{bottom:0,force3D:true}, delay:0.25});

your animating the CSS bottom property.. but i noticed in your style sheet you have the CSS bottom property set to -81%

#betPlacer {      bottom: -81%;}

instead of that you could:

  • calculate the #betPlacer and #betPlacer .bet__slip height.
  • Subtract the two elements height
  • Then use the GSAP set() method to set the bottom property to the negative value of the added height.

the computed bottom should be around the same:

  • with -81% the computed is: -329.683px ( sub-pixels )
  • heights pre-calculated, computed is: -322px ( not sub-pixels )

so maybe the issue is when animating the bottom property the pixels are actual computed as sub-pixels when they are computed from -81%... which might be causing pixel snapping.


if you were animating using translateY .. there wouldnt be an issue animating sub-pixels and it would happen on the GPU layer vs animating the bottom property on the CPU layer.

you could try using force3D:true on your to() tween also

i tested this on a Galaxy Tab and Samsung Galaxy S3 on Android version - 4.1.2 and it animates smooth now

quick note:
you dont have to use the vendor prefix's for any border-radius properties:


see if the above helps :)

  • Like 3
Link to comment
Share on other sites

Just for the record, this sounds like it's unrelated to GSAP - usually the biggest bottleneck in cases like this is just the device/browser. Android devices are notoriously slow and the browser isn't nearly as optimized as iOS Safari. The JavaScript execution usually isn't at fault either - it's the graphics rendering pipeline. So, for example, it might take 0.01% of the resources to run the GSAP code and 99.99% for the browser to calculate the DOM flow, feed the graphics to the GPU and render them all. Try to build your project so that it minimizes the demand on the browser and GPU (natively-sized images, small areas of change, use transforms rather than top/left/bottom/right, etc.) 

  • Like 4
Link to comment
Share on other sites

Firstly thank you Jonathan and Jack! some amazing tips there. 


I was never in doubt that the performance issues were not the fault of GSAP, i was just wondering if anyone had a few tips on how to improve things on android.


Once again greensock delivers! Not only the platform but the community and support is second to none! :)

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.
  • Create New...