CSS3动画和过渡 - 浏览器在动画图形背景或DOM元素方面更好吗？

Question

我正在开发一个网络应用程序;其中一个设计要求是几个大型CSS3动画。

具体来说 - 它有一个很大的<div>，它将在屏幕上转换以响应用户输入。

由于应用程序的设计方式，<div>的“内容”可以实现为设置为<div>的大型静态图形（例如，.jpg或.png）背景

或者，内容也可以使用标准HTML实现。 （内容布局本身是一个“小”的棘手 - 它需要几个浮动或定位的嵌套div元素和跨度，但没有什么疯狂。）

我的问题是 - 哪个选项可能会产生最好（最流畅）的动画？

（我显然可以自己测试一下，但通常很难判断动画的流畅程度，特别是在各种设备上的十几种不同的浏览器中。我也意识到还有其他考虑因素 - 例如维护。但是在这种情况下，我完全专注于动画表现。）

我想知道浏览器是否通常更好地动画/渲染简单的DOM元素 WITH 图形背景，或更复杂的DOM元素（有很多孩子） 没有 图形元素？

另外 - 还有其他指导方针吗？如，

• 浏览器是否比其他浏览器更好地动画某些类型的图形元素？ （例如.png vs .jpg）
• 当子元素具有position:absolute，子元素浮动时，或子元素的位置是否由常规文档流确定时，浏览器是否更好地为元素设置动画？
• 对嵌套元素进行不透明度，阴影或3D变换等操作会对父元素的动画产生负面影响吗？
• 动画性能是否会因元素的复杂性而降低？例如，具有十几级嵌套DOM元素动画的元素是否比仅具有文本节点的简单元素更不顺畅？

我对这些事情有直觉（深层嵌套的DOM元素将比简单元素更不容易动画），但我的直觉常常是错误的。所以，我想知道是否存在关于浏览器或多或少有用的“规则”。

当具有大量子元素的大元素被动画化时，我还应该考虑什么呢？

Answer 1

您的答案将取决于每个实施所使用的具体呈现策略，但如果您可以将WebKit的策略用作“常规”策略，那么您的所有答案都在本文档中：

http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome

首先创建DOM树的“RenderObject”克隆

在此之后，遍历树并将每个RenderObject合并到其最近祖先的RenderLayer中 如果其中一个对RenderObject是真的，请转到一个新的RenderLayer中：

• 这是页面的根对象
• 它具有显式的CSS位置属性（相对，绝对或变换）
• 透明
• 有溢出，alpha遮罩或反射
• 有CSS过滤器
• 对应于具有3D（WebGL）上下文或加速2D上下文的<canvas>元素
• 对应于<video>元素

在此之后，遍历树并将每个RenderLayer合并到其最近祖先的GraphicsLayer中 如果其中一个是关于RenderLayer的，那么或者进入一个新的GraphicsLayer：

• 图层具有3D或透视变换CSS属性
• <video>元素使用加速视频解码来使用图层
• 图层由具有3D上下文或加速2D上下文的<canvas>元素使用
• 图层用于合成插件
• Layer使用CSS动画作为其不透明度或使用动画webkit转换
• 图层使用加速CSS过滤器
• 图层具有作为合成图层的后代
• 图层有一个较低z-index的兄弟，它有一个合成图层（换句话说，图层在合成图层上呈现）

因此，我知道这通常如何工作并在这里采取预感，我不得不说首先最小化导致创建新GraphicsLayer的事情然后最小化导致创建新RenderLayer的事情。只要额外的节点不会导致新的RenderLayers或GraphicsLayers的创建，你就可以逃脱大量的DOM节点嵌套或者你正在讨论的任何东西。

还有关于发送DOM元素向量的位图图像而不是向量本身的想法。我真的怀疑它会更快。对我来说，PNG或JPEG以某种方式表示DOM节点比向量更有效的方式对我没有任何意义。但是，嘿，我没有编写Webkit代码，所以我想真正知道的唯一方法就是对它进行分析。