Myth busting the HTML5 performance of transform:translate vs. top/left(blog.tumult.com)
blog.tumult.com
Myth busting the HTML5 performance of transform:translate vs. top/left
http://blog.tumult.com/2013/02/28/transform-translate-vs-top-left/
2 comments
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.
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.
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.
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.
Ok, I just read the code, and it looks like the transition/translate tests are setting the final values and a duration. Looks like the numbers for these tests are the highest for each browser, as I expected.
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?
There is a webkitTransitionEnd callback. But it alone isn't sufficient for complex animations that could be made with Tumult Hype.
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.