CSS3 中实体元素与透明元素的性能对比

Question

渲染纯色和透明色时的性能差异是什么。时间loading和scrolling网页。假设它们都由 GPU 处理，差异变得很小，但我仍然想知道。生成透明元素需要采取哪些额外步骤，透明元素在 FPS 上的权重是否比常规元素重？

从技术上讲，这不仅限于颜色，而是solid elements与transparent elements.

选择的JSFiddle Demo颜色是 SO 绿色 :)

CSS

.example1{
  background-color:#75845c;
  color: #e1e818;
}

.example2{
  background-color:#75845c;
  color: rgba(255, 255, 0, 0.6);
}

HTML

<div class="example1">
  I am a solid color
</div>
<br />
<div class="example2">
  I am a transperant color
</div>

Answer 1

简短回答：依赖于浏览器。现在为长答案...

[作为背景，我是从一个人的角度来讨论这个问题的，他一直将混合、拼凑和合成像素作为生活中令人尴尬的大当务之急，从早期 DOS 游戏中的插入视频内存到低级 UI 套件和绘图库到今天的光线追踪器和 GPU 着色器。它的核心始终是图像处理。我的工作通常与网络分离并且相当低级，但这似乎是一个更具概念性的问题。我从未实现过 Web 浏览器，但已经实现了许多通用 Web 浏览器所需的相同光栅化技术，并针对具有脚本和节点编程的插件架构，面临许多类似的设计和优化挑战和妥协，浏览器实现者将不得不面对所有可能性。]

Alpha-Blending 便宜

在峰值概念级别，尤其是在这种上下文中，alpha 混合像素的成本非常低，您可能永远不必担心这个成本（除非您每帧渲染数百万个粒子或类似的东西）。在覆盖内存中的目标像素之前，将像素混合在一起只需要一些基本的算法。

即使是基本的 CPU 实现也可以每秒处理数亿个像素（其中涉及的每个像素都被 alpha 混合），并且快速 alpha 混合在图像处理和光栅化的上下文中是一个经过充分研究的问题，其中非常优化从快速 8 位 lerps 和缩放到利用 SIMD 等最近的硬件趋势，解决方案已经为人所知多年。当涉及 GPU 时，算术运算会以极快的速度进行（而且它们已经非常快了）。

但 Alpha-Blending 可能需要不便宜的东西

但是，这是一个孤立的案例，仅研究混合透明元素的成本。围绕此存在各种复杂因素，可能会使渲染透明元素成为热点。

首先，GPU 扫描线光栅化旨在完成比简单地将图像混合在一起更复杂的事情。在每个片段的基础上，涉及顶点变换以及着色和照明。即使你不使用这些东西，而是使用扫描线光栅化来将这些图像显示为纹理，硬件/光栅化管道也被设计来做这些事情，并且无论如何都必须付出很大的代价。结果，通过扫描线光栅化的 alpha 混合可能开始成为瓶颈，但这不是因为 alpha 混合算法。这是因为 alpha 混合片段始终必须支付全部渲染成本，并且不能被涉及 z 缓冲区的深度测试排除。

然而，在使用 GPGPU 而不是扫描线光栅化的上下文中，这变成了一个非问题（例如：使用 GPU 对最初存储在系统内存中的图像进行一堆算术运算，而不涉及完整的 GPU 扫描线管道）。然而，这正在成为一种猜测，如果他们选择使用 GPU，许多浏览器可能更喜欢普通的 GPU 路线，而不是 GPGPU，因为它是更广泛支持、更成熟的路径。

另一个突然出现的问题，但在 3D 上下文中更多的是，许多形式的 alpha 混合就它们提供的结果而言是特定于订单的。片段呈现的顺序很重要。在 3D 环境中，如果我们有 100 万个半透明多边形要渲染，现在我们必须以深度排序的顺序渲染它们的片段，以确保一致、正确的结果。即使使用像双深度剥离这样的非常优化的近似方法，这种排序开销也是非常昂贵的。

然而，在 2D 上下文中，这个深度排序问题通常变得没有实际意义。2D 上下文通常可以简单地根据开发人员请求绘制事物的顺序来产生所需的结果。2D 元素通常也具有恒定的深度（其深度不会因每个片段而变化），因此它不会与基于每个像素/片段渲染的其他元素的深度相交/重叠。

一个不太理想的世界

可能与这个一般问题最相关的是，即使接近理想的概念水平，也很少优化事物。

在不太理想的实现中，对 alpha 混合的需求可能会引起辅助需求。例如，在某些实现中，您进行 alpha 混合的内容可能开始变得非常相关。

例如，如果您在渲染的透明前景元素后面有一个静态背景，这种不太理想的实现可能必须更频繁地（以及更多地）处理背景。理想情况下应该。浏览器必须处理涉及客户端脚本和小程序的动态世界，其中图形可能会根据无限可能的条件而改变。

引入透明元素可能会破坏他们关于静态与动态的假设，并且可能需要对昂贵的背景元素进行额外的重新处理（例如：每次滚动时）。至少我在这里看到了一些与性能相关的问题，这些问题似乎表明可能是这种情况，其中引入一个非常简单的透明元素（绘制起来应该很便宜）对性能产生了巨大的负面影响，并且很可能是由于对浏览器不再能够做出明确假设的静态元素进行重复、冗余的处理。当然，这都是猜想。

在更简单的层面上，alpha 混合多层确实需要检查每一层的内存。如果你说，即使 alpha 混合了一个巨大的图像上的一个很小的透明元素，即使 alpha 混合过程只需要合成少量的像素，它仍然必须移动这个巨大图像的部分内存（它没有在这种情况下，跨扫描线的参考位置非常好）从慢得多的内存区域一直向上缓存层次结构并进入寄存器*。根据此合成过程发生的频率以及浏览器为降低此频率而缓冲的程度，它可能会成为一个实质性的瓶颈。

_{* 为简单起见，我将避免在没有缓存的情况下进行流式加载/存储——无论如何，通常存在相同类型的内存趋势。}

如果您遇到过这样的情况，解决此类问题的一个非常通用的方法是使复合材料中涉及的层更便宜。例如，史诗背景图像可以分解为拼接在一起的较小图像，只有特定的较小图像需要合成。这提高了缓存局部性，即使通常会在逐个像素的基础上应用相同的工作量来将这两个元素组合在一起*。

_{* 计算中一个常见的误解是，做相同的工作量，甚至执行相同的指令，将具有相同的成本。有动态的硬件和操作系统因素使许多指令具有可变成本，其中最值得注意的是硬件将内存从较大但较慢的内存类型移动到更快、较小类型的内存并在软件后面开发商回来了。}

滚动和加载

渲染纯色和透明色时的性能差异是什么。时间loading和scrolling网页。

同样，阿尔法混合非常便宜。然而，透明元素可能会破坏一些潜在的优化，这些优化不太理想的浏览器可以对不透明元素进行。这在滚动中比加载更有可能出现（因为加载只需要发生一次）。

结论

简而言之，在这个问题的上下文中，alpha 混合过程本身非常便宜。甚至要让它成为一个问题，通常需要混合数以百万计的像素，甚至开始显示为可能需要担心的事情。

然而，为了将像素混合在一起所涉及的辅助过程，尤其是在那些不太理想的现实实现中，可能开始变得昂贵。不幸的是，如果不知道特定浏览器的实现，就不可能对这些进行精确细分，但是上面的这些点应该涵盖了很多广泛的可能性。