Glitchy animation on iOS

[cbetta]

I keep getting quite a glitch on iOS (not on web):

Anyone got any idea why this is? I'm using a liquid-outlet and a toLeft/toRight animation.

[cbetta]

So this seems to have something to do with having an overflowing panel in my UI. If I limit it to 3 items it renders fine.

[runspired]

@cbetta are you referring to the stuttery frames? I'm not picking up on any other animation issues here.

[frederikbosch]

@cbetta You might want to try GSAP. See the example by ef4 on the Ember forums. This library has much better performance than velocity.js which is now used for transitions.

[runspired]

@frederikbosch I'm not sure GSAP has better performance, nothing I've seen suggests one library is substantially better than the other, if you have evidence or links that say otherwise I'd love to have them because I've been wondering about this myself.

Some useful resources:

http://greensock.com/css-performance

when nesting could be avoided, pure CSS animation of only transforms did appear smoother on webkit browsers under heavy pressure and it was basically indistinguishable from optimized JS animations under all other levels of pressure.

comparisons:

• http://codepen.io/GreenSock/pen/pmknI
• https://jsperf.com/css-vs-velocity-vs-tweenmax/8 (something seems off on this one, jQuery is killing it)

I think based on some of these results it may be time to completely revisit the conventional understanding of "what's fastest". I'd be willing to rewrite all the default transitions with a different animation library and publish them as an addon if someone want's to create memory and CPU usage benchmarks showing which is actually fastest.

One thing to note with Paul Irish's comment in the video/article at the first link: I think all the in-the-box transitions we're doing meet his criteria of "non-nested", meaning we might be making an optimization here that's hurting us, not helping us, by avoiding CSS transitions.

[runspired]

Another interesting comparison: https://popmotion.io/guides/feature-comparison Which I found here: https://www.reddit.com/r/javascript/comments/3myzj0/popmotion_vs_velocity_vs_greensock_animation/

[runspired]

I think the most fair comparisons of raw ability would be to re-create this with velocity: http://greensock.com/js/speed.html

or this with GSAP / tweenLite / tweenMax http://julian.com/research/velocity/demo.html

And we'd additionally want to create a worst-case scenario in Ember simulation.

We'd want to take these measurements:

• CPU usage
• Memory usage
• FPS

FPS alone isn't a good metric because it's possible to trade memory usage for CPU usage in some places to achieve the same frame rate. With an ember app undergoing a transition, high CPU usage will slow the frame rate a lot, while high memory usage tends to be more tolerable (to a point).

FPS only tells us how well the library does in the demo, it doesn't tell us how well the library does under loads that aren't just animation, which is what really matters.

[frederikbosch]

@runspired You are right. I believe such tests have not been done before. It would be awesome if you could do some tests! I also have some performance issues in my app with transitions, especially on mobile.

Thanks also for the links, I also read the post/comment by Paul Irish, and the corresponding Twitter conversation, very interesting! However, it is very hard to believe for clients that such a thing is so hard on mobile. If we could just define some best practises, that would help most people I guess.

[runspired]

This could be a reason to go with GSAP: https://www.youtube.com/watch?time_continue=110&v=5t6H_x7C2Sc

[frederikbosch]

@runspired That is amazing! Exactly what we need! Especially because the web is (mostly) single threaded! Hurry up with your skyrocket project ;)!

[ef4]

The flicker that's visible in the recording is probably not due to just being "too slow" (although a slow mobile device may make the problem visible).

There are a couple things that could cause flicker like this. Possibly some CSS is messing up the positioning of the content so that when both old and new content are in the DOM, they're not stacked properly on top of each other.

Or possibly there is a timing bug in liquid-fire or velocity that is letting the browser paint a frame with no content visible, instead of synchronously switching from one state to the next.

[runspired]

@ef4 I agree, I've just also been thinking of testing different implementations and let the thread devolve to that, sorry :troll:

[frederikbosch]

@ef4 While I agree on mostly what you are saying, I do not think it can harm to test different animations libraries.

@cbetta Just created this gist. Both files should be added to the folder app/transitions. Furthermore, you should add "gsap": "~1.18.2" to your bower.json and add the following two lines to your ember-cli-build.js.

app.import('bower_components/gsap/src/uncompressed/TweenMax.js');
app.import('bower_components/gsap/src/uncompressed/TimelineMax.js');

Not necessary but to complete, add "TimelineMax" and "TweenMax" to your .jshintrc. Of course, I should have created exports for them, but let's try this first. Then, adjust your app/transitions.js file and change toLeft and toRight to gsapToLeft and gsapToRight.

Please share your results. What do you think, is gsap doing better than velocity? If you have any comments how to improve performance, let me know, because I am looking for the best results too.

[runspired]

@frederikbosch @cbetta alternatively, ember-tweenlite is available and liquid-fire-tweenlite is coming soon. I chose to use tweenlite over tweenmax + timelinemax for keep the imported code as light as possible. Tweenlite contains every feature needed, tweenmax and timelinemax are mostly sugar over the top.

[frederikbosch]

@runspired You are right, it is sugar over the top. My example was quickly made in order to do comparison between libraries. And great that you are building liquid-fire-tweenlite!

[runspired]

@frederikbosch you should follow along, it's getting close https://github.com/runspired/liquid-fire-tweenlite/pull/1

[frederikbosch]

@runspired What are you results regarding performance? I guess you did some kind of comparison already.

[runspired]

@frederikbosch very basic testing, less than ideal circumstances (e.g. not as much stress as I'd like) suggests tweenlite will perform marginally better. I think the real win is in feature set (such as lagSmoothing and delay) not necessarily head-to-head perf. There may be a very slight win in head-to-head too.

[runspired]

@frederikbosch are you not in the Ember Slack?

[frederikbosch]

@runspired Nope, I am not a Slack user at all. Maybe I should. But I am reluctant using another medium. IMHO it is usually just distraction from work.

[runspired]

@frederikbosch what's a good way to chat then? Also, you are missing out on a LOT with the Ember Slack, especially given the number of addons I see you use and contribute to.

[frederikbosch]

We could create a section performance in the documentation. Or, since there is movement to split this repo into a core and multiple animation implementations, we could also create a section implementations.

[deepflame]

@cbetta have the same issue in my app running on iOS. Also same here: if the dom does not extend the overflow area everything is fine. If it exceeds it flickers.

Did you manage to solve it?

[averydev]

Wow, I just tried runspired/liquid-fire-tweenlite and mobile performance is SO much smoother. Thank you!