

Myth busting the HTML5 performance of transform:translate vs. top/left - ryannielsen
http://blog.tumult.com/2013/02/28/transform-translate-vs-top-left/

======
fzzzy
Hmm. I'm not sure why anybody would think that using transform in a javascript
callback loop would be faster than setting top/left in a javascript callback
loop. However, it's obvious why using tranform and css animations would be
faster: there's no javascript loop required.

If animating in javascript, every frame requires a new javascript turn, and
every frame requires crossing the js/native bridge. Theoretically it should be
faster to cross the bridge only once, which is possible when using translate
because both x and y can be set in one crossing of the bridge, wheras setting
top and then setting left requires crossing the bridge twice. However the cost
of setting up and tearing down the turns required to do the animation in js
would dwarf any tiny advantage gained by only crossing the bridge once instead
of twice.

However if you instead simply use a transform with a duration and set the x
and y to the final value instead of manually setting all the intermediate
values, it's obvious why things should be much faster: there are no longer any
js turns required to carry out the entire animation other than the first one
where you set it up, and there's no bridge crossing required except for the
first one, either.

Did I miss something here? Why would the author think that setting transform
in a loop would be faster than setting top/left in a loop? They are basically
equivalent. CSS animations with a duration are vastly different, however.

~~~
tumultco
I didn't go in with any assumptions. There's been lots of advice given that
using transform:translate() is always the fastest path; the point of this was
to measure and see. Also knowing something is faster isn't the same as knowing
_how much_ faster. This can have implications when deciding what technology
and tradeoffs to use.

Besides, is it really obvious that top/left would be faster (in a non-
transition case)? It requires an additional layout phase compared to
transforms:translate().

On the common sense of transitions being faster, it is true that there will be
overhead in running JavaScript code. But at the same time, 1/60th of a second
is a very long time for a computer and (for me) the overhead of crossing the
bridge and running a minimal amount of JavaScript was an unknown.

Being from the "show me state" I like to measure before doing any performance
optimization work or making general claims.

~~~
fzzzy
Cool, thanks. I understand better now what you were saying in the blog post
because I read it a few more times after I wrote that comment.

Also, I think you may be surprised how much overhead crossing the bridge from
js to native incurs. It's pretty negligible in most cases, but for things like
animation it can be a killer.

------
leeoniya
i'm assuming there's no "callback" or event to "listen" for that can be hooked
to identify the end of the animation when using the translate method, you just
have to rely on the preset duration?

~~~
tumultco
There is a webkitTransitionEnd callback. But it alone isn't sufficient for
complex animations that could be made with Tumult Hype.

