Android WebView frame pacing

[Jon Pierce]

I am running greensock animations within a WebView in an android app and I am getting random "choppi-ness". 

After running tests, I am suspecting that the frame pace of the Android app and the pace of the greensock timeline are out of sync. 

This may be causing an animation to last longer than a frame and causing jumpiness in the animation.

The GPU performance is showing that the animation frames are taking less than 16ms to render but still a visual chop to the animation.

 

Has this ever been explored?

I could be way off base for the cause of the chop but I have done "force3D" to force it onto the gpu and I am certain the code is right since it does clear up in a normal browser, however, there isn't a significant change in the Android WebView.

 

https://developer.android.com/games/optimize/frame-pacing

[GreenSock]

Hey @Jon Pierce. Welcome to the forums! 

 

By default, GSAP uses requestAnimationFrame which is standard in all browsers (except ancient ones, in which case GSAP falls back to setTimeout()). The whole point of requestAnimationFrame is to ensure that it's perfectly synchronized with screen refreshes. So unless the WebView in the Android app isn't using that (which would be very surprising to me), it should all be synced up nicely. Do you know if the device you're testing on supports requestAnimationFrame? 

 

Typically when there's jank, it has nothing to do with GSAP specifically because it's so highly optimized and updating its values accounts for a very small portion of the overall load - it's almost always related to graphics rendering in the browser. So, for example, if you're animating 100 SVG elements, GSAP might take up 0.5% of the overall CPU load to do its work, and 99.5% is the browser actually fabricating all the new pixels for the resolution-independent SVG elements, firing events, doing any document reflows, etc. 

 

You could certainly experiment with actually setting force3D:false just to see if it helps anything. Usually it's best to leave force3D:"auto" or true, but in some rare cases the browser may actually do better with it disabled (Chrome on the Mac currently has a bug that actually can decrease rendering performance with 3D layering enabled). 

 

Another thing you could experiment with is setting TweenLite.ticker.fps(30) or something to set it to a lower-than-normal value just to see if visually it helps you. I kinda doubt it will, but it's worth a shot.