-
Notifications
You must be signed in to change notification settings - Fork 174
FAQs
Tween is a term used by animators and software engineers to define the numeric start, end and the inbetween values used in digital animation, while the digital animation uses these tween values on a given frequency (interval) or scaled by hardware capability (monitors refresh rate, GPU vertical sync, etc). The term was introduced to the world of web development by early Javascrpt libraries and later used in dedicated animation libraries such as GSAP, Dynamics, Velocity, Shifty, our own KUTE.js here and many others. When used as a verb, it actually refers to the interpolation of the values.
Tween Object is a JavaScript Object that stores temporarily or for a given time a set of variables such as tween values, HTML elements to animate, CSS properties and other tween options to be used for animation. To improve performance on repetitive animations, this object can be cached and reused whenever needed. In JavaScript animation, the term tween actually refers to the tween object.
polyfill is a term introduced by Remy Sharp back in 2009 as "a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively". Basically a polyfill covers what legacy browsers don't support or in other cases corrects the implemented behavior that is different from the standards. More details.
requestAnimationFrame is a Javascript method developed to enable hardware accelerated animations for the web today. In Javascript, the window.requestAnimationFrame(callback) method is all we need to setup animations really for all the above mentioned animation engines. Some developers built a polyfill to cover the legacy browsers chaos.
JANK is a term used when browsers miss frames due to long script execution and/or long layout recomposition. JANK is the phenomenon reffering to severe frame drops. Luckily there are people who explain all about it, so you don't have to stay in the dark.
As said before, performance varies from case to case; this chapter aims to explain what you should expect working with animation engines in these various scenarios at maximum stress, usually when your CPU cooler starts to work really hard, and how scalable performance can really be on various machines, operating systems or mobile devices. We'll dig into each case, by property type or anything that can be considered a factor of influence.
This could be one of the most important factors that influence performance, because we neglect this fact most of the time and changing the scope of an animation engine is important to look after. A quick example would be when we create tween objects on events such as click, scroll or resize, we basically set a totally different scope for the animation and we fill the memory with large chunks of trash/jank, especially on events like resize.
A better way to handle this is to create the tween objects outside the event handlers and only start the animation with these handlers when certain conditions are met. EG: if (window.clientWidth > 760) { myTween.start() }. Also keep in mind that this approach will eliminate any possible sync issues, but creating many animations is a huge temptation and this will create lots of problems for the old browsers, so keep the function nesting to as minimal as possible as a general rule.
While the code execution is the fastest for the layout modifiers or what we call the box-model properties, say the position based properties set such as left or top, they may force the entire page layout to change if not absolutely positioned and thus requires the browser to repaint all elements affected by animated repositioning and their parent elements. On the other side translate doesn't trigger a repaint but involves more complex operations such as more object traversing, string concatenation or check for certain conditions to be met. All of this is because translate is part of transform CSS3 property that has to stack in a single line many more properties such as rotate, skew and scale. An article by Paul Irish explains more about differences in performance between position and translation.
Also any transform property is sub-pixel enabled and requires one or more decimals for accurate and smooth animation, decreasing overall performance. That said and with the emerging high resolution displays, it's safe to speculate that at least translation could be optimized by rounding the values, while scale, rotation and skew requires three decimals.
To put it short left executes faster but requires repaint on every frame while translateX or translate3d execute slower but require no repaint on each animation frame. The winner is left, when it comes to code execution speed, but if we also count the elements' size, the larger size the more favor the translation so the overall winner is translate. The more pixels to recompose in the layout, the more time spent on each frame, and this is why translation is better in most cases, and animated positioning is best to be used as fallback animation for legacy browsers.
While running a 2D translate:150 animation could score similar performance as translateX:150, interestingly, translate3d:[150,0,0] is slightly faster than the other translations. Some performance tests confirm that translate3d is the preferred property for hardware acceleration. For this reason, translate3d is the winner and KUTE.js always uses it even if you only use translateX or translateY for instance.
Similarly, if you animate the 2D translate this always goes translate(x,y) even if you use translate:150 (only for the X axis) or translate:[150,0] (both X and Y axis), for better performance as well. And by the way, this works great on IE9 and other legacy browsers.
We compared position with transition above, but now we are going to talk about other issues related to resizing properties: width, height, margin, padding and borderWidth or any of their variations. The code execution is super fast, but when resizing the window while animations are running, the browser is also computing the resize handlers, the animation performance is very very low on all browsers, especially when you animate these resize properties. When this toxic combination occurs animating a large amount of elements could crash any browser, no exception, and I think any developer should know about this.
The resize event triggered by these resizer properties can cause some severe issues with legacy browsers such as IE8. These good old browsers don't understand much about JavaScript driven layout changes and thus skip/fail to execute any handlers attached to window resize event bubbles.
A workaround for the resizers' effect on the layout would be to use them only for absolute positioned elements, this way the layout will not need to be repainted and the re-composition is limited to the elements themselves. If not, and you are required to provide legacy support, you must DISABLE any resize handlers for IE8 and any other browser that runs slow or crashes. You should also consider not using any resize animation for legacy browsers especially when usability and larger reach is expected.
When animating any color property such as (text) color or background-color, KUTE.js always uses/converts to RGB/RGBA, and a function to transform the color value to HEX format will impact performance.
TO and FROMTO
The two main methods for creating animation setups (tween objects) that are coming with KUTE.js are .to() and .fromTo(). While .to() is much more simple and convenient to use, very useful for tween chaining, it has to process the starting values on every .start() delaying the animation for a few milliseconds depending on the browser and hardware, making .fromTo() the winner. On a large amount of elements animating at the same time, these scripting based delays can produce some serious sync issues, so caution is advised. In that case you should use .fromTo() properly.
KUTE.js comes with 2 packs of easing functions: the popular easing functions by Robert Penner and cubic-bezier-easing we developed based on Apple's CubicBezier. The Robert Penner's functions in any performance test, that's an all time winner due to it's simplicity at the cost of precision, while the other one has more precision at the cost of more than manageable precision loss.
The point here is that the more accuracy a function offers, the more power needed, and the result is less performance. For instance the cubic-bezier based functions have a 0.0000001 error margin, while the Exponential easing functions by Robert Penner are somewhat glitchy on long page scrolls or translations. Generally the difference in performance is fairly negligible even for large amounts of elements, and have no impact on very few elements.
The goal of the development strategy is to be able to execute the script, update layout and repaint, all under 16 milliseconds or less (on higher refresh rate displays), so that the animation runs constantly at 60fps. However running some repeatable animations for a large amount of elements would really give garbage collectors a lot of work and thus some frames take more than 16 milliseconds. The more properties and/or elements, the more work.
While garbage collection is a great way modern browsers use to clean the memory, sometimes the garbage collector can jump in anytime, causing drops in the order of milliseconds. Still, if it's the case, there are ways to help composing the layout faster, but we will see that in the performance testing page.
Just like the high amount of simultaneous animations influence performance, the property value complexity is also an important factor. If we were to compare all the supported properties in terms of complexity, the list would go like this (from most expensive to least): path morphing, regular and matrix3d transform, filter, box-shadow / text-shadow, colors, box-model*, unitless props (scroll, opacity).
*Box-model properties of type resizers have additional performance drawbacks as discussed previously.
The performance tests have been performed mainly on Microsoft Windows 8.1 and Ubuntu Linux 14.04 Trusty Tahr with latest nVidia graphics drivers on both OSs, all set up for maximum performance. The browsers are obviously Firefox (both OSs), Google Chrome (both OSs), Opera (both OSs) and IE11 (Win8).
The results show Windows based browsers came better than Ubuntu based ones, mainly because of DirectX and better drivers that greatly improve hardware accelerated graphics, while Linux still faces some noticeable issues with vertical sync among many others, but hey it's a work in progress and it's open source!
The browsers' performance goes like this (from best to poorest): Google Chrome, Opera, Internet Explorer, Firefox. Yes, Firefox is the slowest on Windows OS. I never tested anything on iOS or MAC-OS but I believe Safari performs very well with transforms. Some argue that Safari outperforms Google Chrome due to the latest Webkit upgrade.
Also know that legacy browsers don't support requestAnimationFrame and polyfills usually replace it with setInterval, a classic JavaScript method that's significantly affecting performance, because it's one of the main causes for lots of JANK.
Another important aspect as far as performance goes, the power saving profiles on Windows OS drops performance for desktop computers and especially laptops. Also when a laptop is unplugged, Windows automatically changes power profile drastically decreasing performance.
As for the mobiles, you must know that even if you have an octa-core CPU powered phone or tablet is never going to match a desktop and not even a laptop. For a mobile device these guys recommend to keep everything under 7 milliseconds for the smooth experience that most users expect and that the animation performance of a phone is actually up to 5 times lower than a desktop or laptop. I would stress that having 2 or 3 simultaneous animations on a phone at a certain point is just about enough.
Another thing to keep in mind is that scrolling on a mobile device is actually hardware accelerated animation and thus compete for power drastically reducing performance for any other CSS or JavaScript driven animations. To understand how critical performance is on a mobile device, I highly recommend checking the Google I/O 2014 presentation. Now you understand how much performance really matters.
Remember: do not open any JavaScript animation engine performance test with your phone, you may burn your battery, especially if it's unpluggable.
Found a typo or something? Report it!