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.
Related
I wonder, if it is more beneficial to use the abilities of QML for animations, or prefer to use animation files (such as GIF oder MNG) for simple, small-scale animations.
Examples for what I call "simple, small-scale animations" are:
turning Hourglasses
those rotating dots, known from video platforms, while loading
flashing alert symbols
those "recharging buttons" known from many RPGs used for special attacks
I don't know much about the internals of Qt, so I am unsure, whether I benefit from hardware acceleration, when programming the animations (e.g. image rotation) or not. And if so, whether this hardware acceleration outperforms the display of pre-calculated animations from GIF and MNG.
Greetings and thanks,
-m-
I wouldn't worry about things like this unless they visibly slow the performance of your application. Some points to consider:
The use cases you mentioned almost always involve only one "busy indicator" being visible at a time.
Both Image and AnimatedImage have the high DPI #*x file look-up.
Both Image and AnimatedImage support caching.
Both Image and AnimatedImage will use the Qt Quick scene graph to display the images (OpenGL textures, which should result in hardware acceleration).
AnimatedImage has to read several images, but won't require rotation.
Rotation of images is pretty cheap, as far as I know.
It's trivial to swap out one with the other, or with something else.
If you're looking for good general performance advice, read the Performance Considerations And Suggestions documentation.
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.
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.
I remember seeing some articles about using Pixel Blender to speed up performance on heavy computation, but i cant find them anymore. Can anyone suggest an article on this?
http://www.adobe.com/devnet/flex/articles/flashbuilder4_pixelbender.html