I am making an app and realised that it is best to hardware accelerate animations.
I wanted to use jQuery animate enhanced, which works but I feel I want a better grasp on the whole idea of hardware acceleration:
When moving a div using top/left positioning for example using jQuery, will it automatically be hardware accelerated by adding transform: translate3d(0, 0, 0); ?
Will this hardware accelerate anything? Also, what about animation keyframes? Will you need to add a transform to an animation for it to be hardware accelerated?
Paul Irish wrote a great, in-depth breakdown of this very thing.
Usually 3d translation will trigger the GPU, if it doesn't, it's no big deal, it still works. Using translate over left/top coordinates is usually better performance-wise as well. I'm not sure about the animation keyframes part of the question though.
Related
As the title says, what are the differences between transform: translate(x, y) and position: relative.
Since they both accomplish the same thing (position elements) anyway, then how do they differ in purpose and application?
I read an article about centering elements using "transform: translate;" that said it is better to use "transform" due to GPU and optimization reason, but I don't really see the problem since it's not a big deal anyway if you're just re-positioning an element and not animating it.
So in the end, how are they both different and in what ways?
Basically translate relies on CSS3 2D Transforms while the position property is a CSS2 level.
In browser that support it has been said that using translate will boost the entire graphical peformance of the browser,
but not all browser do support it,
so if you care to give widespread browser support CSS2 position is surely better,
while transform:translate() is the future.
I went across change logs of MobileSafari in iOS 6 where it states:
WebKit no longer always creates hardware-accelerated layers for
elements with the -webkit-transform: preserve-3d option. Authors
should stop using this option as a way to get hardware acceleration
Does there exist any list of hardware accelerated CSS properties ?
These aspects of your document can be accelerated by the GPU:
General layout compositing
CSS3 transitions
CSS3 3D transforms
Canvas Drawing
WebGL 3D Drawing
More on this here http://www.html5rocks.com/en/tutorials/speed/html5/
Maybe this article will help toohttp://indiegamr.com/ios6-html-hardware-acceleration-changes-and-how-to-fix-them/
And this one http://mobile.smashingmagazine.com/2012/06/21/play-with-hardware-accelerated-css/
Paul Lewis & Paul Irish have a really good article about High Performance Animations.
"We’re going to cut straight to the chase. Modern browsers can animate four things really cheaply: position, scale, rotation and opacity. If you animate anything else, it’s at your own risk, and the chances are you’re not going to hit a silky smooth 60fps."
4 things a browser can animate cheaply
Position - transform: translate(n px, n px);
Scale - transform: scale(n);
Rotation - transform: rotate(n deg);
Opacity - opacity: 0..1;
TranslateZ() or Translate3D() may be required.
Source: http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
Are there any reasons not to hardware-accelerate everything with
transform: translate3d(0,0,0);
Using the * as the selector?
What things should be hardware accelerated and what things not?
#IMUXIxD You ask a really good question and the answer is no you shouldn't hardware accelerate everything it may seem to solve an issue but can actually be causing several other issues. It can also cause weird display issues when you're trying to z-index items as hardware accelerating object tends to remove them from the DOM while animating.
I wrote an extensive article on my understandings and tests with hardware acceleration here http://blog.zindustriesonline.com/gpu-accelerated-animations-and-composite-layering/
it also has a very good video on the subject from Matt Seeley an engineer at Netflix.
I hope this helps you understand a little better the benefits and downfalls of using hardware acceleration and what the best case scenarios are for use cases.
I am moving 10,000 small div elements in a css3 experiment from the top of the browser viewport to the bottom. For this test I use 2 different approaches:
With GPU acceleration using translate3D(x, y, z) or translateZ(0)
No GPU acceleration by simply adjusting the top property in css
Using NO hardware-acceleration runs fairly smooth on Google Chrome.
If I enable hardware-acceleration performance becomes a lot worse. It's so bad the boxes aren't even spread out evenly anymore:
With GPU/Hardware acceleration:
Without GPU/Hardware acceleration:
Question
Why is that so? Shouldn't using the GPU improve performance?
Demo application
https://www.timo-ernst.net/misc/hwtest/
Source
https://github.com/valnub/hwtest
My hardware used for test
Apple Macbook Pro 15" 2015 Model
CPU 2,8 GHz Intel Core i7
16 GB RAM
macOS Big Sur 11.2
Update (2014-11-13): Since this question is still attracting attention I'd like to point out that the problem itself still seems to exist although the mentioned stuttering might not be visible anymore in the provided demo on modern hardware. Older devices might still see performance issues.
*Update II (2021-02-17): The problem still persists but you will have to increase the number of boxes being moved in the demo based on the hardware used. I changed the UI of the demo app so you can now adjust the number of boxes moved to create a stuttering animation for your specific hardware. To replicate the issue I recommend to create enough boxes to see stuttering with GPU/hardware acceleration enabled. Then tick off the box and run the test again without acceleration. The animation should be smoother.
I always add :
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
When working with 3d transform. Even "fake" 3D transforms. Experience tells me that these two lines always improve performances, especially on iPad but also on Chrome.
I did test on your exemple and, as far as I can tell, it works.
As for the "why" part of your question... I don't know. 3D transform are a young standard, so implementation is choppy. That's why it's a prefixed property : for beta testing. Someone could fill a bug report or a question and have the team investigate.
Edit per August 19th 2013:
There's regular activity on this answer, and I just lost an hour finding that IE10 also need this.
So don't forget :
backface-visibility: hidden;
perspective: 1000;
The reason animation was slower when you added the null transform hack (translateZ(0)) is that each null 3D transform creates a new layer. When there are too many of these layers, rendering performance suffers because the browser needs to send a lot of textures to the GPU.
The problem was noticed in 2013 on Apple's homepage, which abused the null transform hack. See http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/
The OP also correctly noticed the explanation in their comment:
Moving few big objects is more performant than moving lots of small items when using 3D-acceleration because all the 3D-accelerated layers have to be transferred to the GPU and the way back. So even if the GPU does a good job, the transfer of many objects might be a problem so that using GPU acceleration might not be worth it.
Interesting. I've tried playing with a few options in about:flags, specifically these ones:
GPU compositing on all pages Uses GPU-accelerated compositing on all
pages, not just those that include GPU-accelerated layers.
GPU Accelerated Drawing Enable GPU accelerated drawing of page
contents when compositing is enabled.
GPU Accelerated Canvas 2D Enables higher performance of canvas tags
with a 2D context by rendering using Graphics Processor Unit (GPU)
hardware.
Enabled those, tried it and failed miserably with the tickbox enabled (just like you did). But then I noticed yet another option:
FPS counter Shows a page's actual frame rate, in frames per second,
when hardware acceleration is active.
Given the highlight in the flag description, I'd speculate that hardware acceleration was, in fact, on for me even without the ticked checkbox since I saw the FPS counter with the options above turned on!
TL;DR: hardware acceleration is, in the end, a user preference; forcing it with dummy translateZ(0) will introduce redundant processing overhead giving the appearance of lower performance.
Check chrome://flags in chrome. It says
"When threaded compositing is enabled, accelerated CSS animations run on the compositing thread. However, there may be performance gains running with accelerated CSS animations, even without the compositor thread."
My expericence is that GPUs aren't generally faster for all kind of graphics. For very "basic" graphics they can be slower.
You might have gotten different result if you were rotating an image - that's the kind of thing GPUs are good at
Also consider that translateZ(0) is an operation in 3 dimensions, while changing top or left is a 2 dimensional operation
I saw you two demo， I think I know the reason you confused：
The animation elements Do not use the left or top to change the location, try to use the -webkit-transform;
All child elements need to turn on hardware acceleration such as use translateZ () or translate3D;
FPS measure animation fluency, your demo FPS on average only 20FPS.
Above, only a personal opinion, thank you!
I've often been told that CSS 3D transforms are hardware accelerated in Mobile Safari which makes me wonder if the implication is that 2D transforms are not? I can think of no reason why they wouldn't be, since they can basically all be implemented as 3D transforms, but I would like to know for sure.
If it turns out that 2D transforms are not hardware accelerated, any insight as to why would be much appreciated.
You're right, CSS 2D transforms aren't hardware accelerated in Mobile Safari, but 3D transforms are. I'm not sure why it's that way, but perhaps they decided it was overkill for most 2D transforms. Using the GPU unnecessarily could adversely affect battery life.
It's very easy to convert a 2D transform to a 3D transform so it isn't much of a problem. One trick is to use translateZ(0) as described here: http://creativejs.com/2011/12/day-2-gpu-accelerate-your-dom-elements/
EDIT
Apple doesn't say anything about it in their documentation, so it is difficult to get an authoritative source. Here is what Dean Jackson from Apple had to say about it (from http://mir.aculo.us/2010/08/05/html5-buzzwords-in-action/):
In essence, any transform that has a 3D operation as one of its functions will trigger hardware compositing, even when the actual transform is 2D, or not doing anything at all (such as translate3d(0,0,0)). Note this is just current behaviour, and could change in the future (which is why we don’t document or encourage it). But it is very helpful in some situations and can significantly improve redraw performance.
Ariya Hidayat from Sencha wrote a post explaining hardware acceleration on mobile browsers: http://www.sencha.com/blog/understanding-hardware-acceleration-on-mobile-browsers/. Here's a snippet from the post:
The best practice of setting the CSS transformation matrix to translate3d or scale3d (even though there is no 3-D involved) comes from the fact that those types of matrix will switch the animated element to have its own layer which will then be composited together with the rest of the web page and other layers. But you should note that creating and compositing layers come with a price, namely memory allocation. It is not wise to blindly composite every little element in the web page for the sake of hardware acceleration, you’ll eat memory.
Here is an article from html5rocks.com that discusses hardware acceleration: http://www.html5rocks.com/en/tutorials/speed/html5/. Here's a snippet from it:
Currently most browsers only use GPU acceleration when they have a strong indication that an HTML element would benefit from it. The strongest indication is that a 3D transformation was applied to it. Now you might not really want to apply a 3D transformation, but still gain the benefits from GPU acceleration - no problem. Simply apply the identity transformation:-webkit-transform: translateZ(0);
Firefox and Internet Explorer already use hardware acceleration for 2D transforms, so I wouldn't be surprised if the WebKit browsers (Chrome, Safari) include it in the near future.