Why does enabling hardware-acceleration in CSS3 slow down performance?

Question

I am moving 6000 small div elements in an css3 experiment using a transition from top: 0 to top: 145px to test performance.

Using n

Answer 1

I saw you two demo， I think I know the reason you confused：

1. The animation elements Do not use the left or top to change the location, try to use the -webkit-transform;
2. All child elements need to turn on hardware acceleration such as use translateZ () or translate3D;
3. FPS measure animation fluency, your demo FPS on average only 20FPS.

Above, only a personal opinion, thank you!

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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."

Answer 6

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;