blocks|key|2894740|text|检查chrome中的chrome://标志。上面写着|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2894741|2894742|“启用线程合成时，加速的CSS动画在合成线程上运行。但是，即使没有合成器线程，使用加速的CSS动画也可以提高性能。”|blockquote|2894743|2894744|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|J|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|K|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|M|8|@]|9|@]|A|$]]]|H|$]]

Check chrome://flags in chrome. It says 

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

blocks|key|2894772|text|有意思的。我尝试过在about:flags中使用一些选项，特别是这些选项：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2894773|2894774|+所有页面上的GPU合成在所有页面上使用GPU加速合成，而不仅仅是那些包含GPU加速层的页面。|blockquote|BOLD|2894775|2894776|当启用合成时，GPU加速绘图启用页面内容的GPU加速绘制。|2894777|图形处理器加速的Canvas+2D通过使用图形处理器硬件进行渲染，实现了具有2D上下文的画布标签的更高性能。|2894778|2894779|启用了这些，尝试了一下，但在启用tickbox的情况下失败了(就像你做的那样)。但后来我注意到了另一种选择：|2894780|当硬件加速激活时，|2894781|+FPS计数器以每秒帧数为单位显示页面的实际帧率。|2894782|2894783|2894784|考虑到标志描述中的突出显示，我推测硬件加速实际上对我来说是开启的，因为我看到FPS计数器打开了上面的选项！|2894785|TL；DR:最终，硬件加速是用户的偏好；用虚拟translateZ(0)强制它将引入冗余的处理开销，从而造成性能下降的外观。|2894786|entityMap^0|A|B|0|0|1|B|0|0|7|7|0|0|H|0|0|0|0|1|6|0|0|0|0|0|9|N|D|0^^$0|@$1|2|3|4|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|17|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|18|8|@$9|19|A|1A|B|J]]|D|@]|E|$]]|$1|K|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1C|8|@$9|1D|A|1E|B|J]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1F|8|@$9|1G|A|1H|B|J]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1J|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1K|8|@]|D|@]|E|$]]|$1|U|3|V|5|I|7|1L|8|@$9|1M|A|1N|B|J]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1O|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1P|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|1R|8|@$9|1S|A|1T|B|J]|$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|12|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]]|13|$]]

Interesting. I've tried playing with a few options in <code>about:flags</code>, specifically these ones:

<blockquote>
 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.
</blockquote>

Enabled those, tried it and failed miserably with the tickbox enabled (just like you did). But then I noticed yet another option:

<blockquote>
 FPS counter Shows a page's actual frame rate, in frames per second,
 when hardware acceleration is active.
</blockquote>

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 <code>translateZ(0)</code> will introduce redundant processing overhead giving the appearance of lower performance.

blocks|key|230333|text|我总是补充说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|230334|-webkit-backface-visibility:+hidden;
-webkit-perspective:+1000;|code-block|syntax|javascript|230335|使用3d变换时。甚至是“假的”3D变换。经验告诉我，这两条线总是能提高性能，特别是在iPad上，在Chrome上也是如此。|230336|我在你的例子上做了测试，据我所知，它是有效的。|230337|至于你问题的“为什么”部分..。我不知道。3D变换是一个年轻的标准，因此实现起来并不稳定。这就是为什么它是一个前缀属性:用于beta测试。有人可以填写错误报告或问题，并让团队进行调查。|230338|根据2013年8月19日编辑|230339|有关于这个答案的常规活动，我只是浪费了一个小时才发现IE10也需要这个。所以别忘了：|offset|length|style|BOLD|230340|backface-visibility:+hidden;
perspective:+1000;|230341|entityMap^0|0|0|0|0|0|0|0|16|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@$Q|15|R|16|S|T]]|9|@]|A|$]]|$1|U|3|V|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

I always add :

<pre><code>-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
</code></pre>

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 :

<pre><code>backface-visibility: hidden;
perspective: 1000;
</code></pre>

blocks|key|3108686|text|我的经验是，对于所有类型的图形，GPU通常都不会更快。对于非常“基本”的图形，它们的速度可能会更慢。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3108687|如果您旋转图像，您可能会得到不同的结果-这是GPU擅长的事情|3108688|还要考虑translateZ(0)是3维的操作，而改变顶部或左侧是2维的操作|3108689|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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

blocks|key|230345|text|我看过你们两个的演示，我想我知道你们困惑的原因：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|230346|使用-webkit-transform;|230347|All+()或translate3D;|unordered-list-item|230348|
|230349|FPS测量动画的流畅度，你的|230350|动画平均每秒只有20fps。|ordered-list-item|230351|230352|230353|以上仅代表个人观点，谢谢！|230354|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|V|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|Y|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

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

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

Above, only a personal opinion, thank you!

blocks|key|233336|text|添加null+transform+hack+(translateZ(0))时动画变慢的原因是每个空3D变换都会创建一个新层。当这些层太多时，渲染性能会受到影响，因为浏览器需要向GPU发送大量纹理。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|233337|这个问题是在2013年苹果的主页上发现的，苹果滥用了null+transform的黑客攻击。请参阅http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/|233338|OP还正确地注意到了their+comment中的解释：|233339|当使用3D加速时，|233340|移动几个大对象比移动许多小项目性能更好，因为所有3D加速的层都必须传输到图形处理器并返回。因此，即使图形处理器做得很好，许多对象的传输也可能是一个问题，因此使用图形处理器加速可能不值得。|blockquote|233341|233342|entityMap|0|LINK|mutability|MUTABLE|url|https://aerotwist.com/blog/on-translate3d-and-layer-creation-hacks/|1|http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/|2|https://stackoverflow.com/questions/10014461/why-does-enabling-hardware-acceleration-in-css3-slow-down-performance#comment22070776_10014461^0|N|D|2|J|0|0|1D|1X|1|0|A|D|2|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@$9|14|A|15|1|16]]|E|$]]|$1|F|3|G|5|6|7|17|8|@]|D|@$9|18|A|19|1|1A]]|E|$]]|$1|H|3|I|5|6|7|1B|8|@]|D|@$9|1C|A|1D|1|1E]]|E|$]]|$1|J|3|K|5|6|7|1F|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1G|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]|$1|P|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]]|Q|$R|$5|S|T|U|E|$V|W]]|X|$5|S|T|U|E|$V|Y]]|Z|$5|S|T|U|E|$V|10]]]]

The reason animation was slower when you added the <a href="https://aerotwist.com/blog/on-translate3d-and-layer-creation-hacks/" rel="nofollow noreferrer">null transform hack</a> (<code>translateZ(0)</code>) 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 <a href="http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/" rel="nofollow noreferrer">http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/</a>

The OP also correctly noticed the explanation in <a href="https://stackoverflow.com/questions/10014461/why-does-enabling-hardware-acceleration-in-css3-slow-down-performance#comment22070776_10014461">their comment</a>: 

<blockquote>
 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.
</blockquote>

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:
<ol>
<li>With GPU acceleration using <code>translate3D(x, y, z)</code> or <code>translateZ(0)</code></li>
<li>No GPU acceleration by simply adjusting the <code>top</code> property in css</li>
</ol>
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:
<h3>With GPU/Hardware acceleration:</h3>
<hr />
<img src="https://www.timo-ernst.net/misc/hwtest/video/gpu.gif" alt="">
<hr />
<h3>Without GPU/Hardware acceleration:</h3>
<hr />
<img src="https://www.timo-ernst.net/misc/hwtest/video/no-gpu.gif" alt="">
<hr />
<h3>Question</h3>
Why is that so? Shouldn't using the GPU improve performance?
<h3>Demo application</h3>
<a href="https://www.timo-ernst.net/misc/hwtest/" rel="nofollow noreferrer">https://www.timo-ernst.net/misc/hwtest/</a>
<h3>Source</h3>
<a href="https://github.com/valnub/hwtest" rel="nofollow noreferrer">https://github.com/valnub/hwtest</a>
<h3>My hardware used for test</h3>
<ul>
<li>Apple Macbook Pro 15&quot; 2015 Model</li>
<li>CPU 2,8 GHz Intel Core i7</li>
<li>16 GB RAM</li>
<li>macOS Big Sur 11.2</li>
</ul>
<hr />
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.

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

在css3实验中，我将10,000个小div元素从browser视口的顶部移动到底部。对于这个测试，我使用了两种不同的方法：使用translate3D(x, y, z)或translateZ(0)No GPU加速的只需调整css中的top属性即可实现使用不使用硬件加速在Google Chrome上运行相当流畅。如果我启...

问为什么在CSS3中启用硬件加速会降低性能？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在CSS3中启用硬件加速会降低性能？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在CSS3中启用硬件加速会降低性能？
EN