performance - 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混合像素的成本非常低，您可能永远不必担心此成本（除非您每帧渲染数百万个粒子或类似的东西）。将像素阿尔法混合在一起仅涉及一些基本算法，然后再覆盖内存中的目标像素。

即使是基本的CPU实现也可以每秒完成数亿个像素的传输（其中每个涉及的像素都进行了alpha混合），而在图像处理和光栅化的情况下，快速的alpha混合是一个经过充分研究的问题，其中非常理想从快速的8位lerp和缩放到利用诸如SIMD之类的最新硬件趋势，解决方案已经有很多年了。当GPU介入时，算术运算将以极快的速度运行（它们已经非常快了）。

但是，Alpha混合可能需要不便宜的东西

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

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

但是，在使用GPGPU而不是扫描线栅格化的情况下，这变成了非问题（例如：使用GPU对最初存储在系统内存中的图像进行一堆算术运算而不涉及整个GPU扫描线管线）。但是，这已经成为一种猜测，如果选择使用GPU，那么许多浏览器可能仍然偏爱普通的GPU路由而不是GPGPU，因为这是受更广泛支持的成熟路径。

另一个出现的问题（但更多是在3D环境中出现）是，许多形式的alpha混合在其提供的结果方面都是特定于订单的。片段的渲染顺序很重要。在3D环境中，如果要渲染一百万个半透明多边形，则现在必须按深度排序的顺序渲染其片段，以确保一致，正确的结果。即使采用像Dual-Depth Peeling这样的最佳近似方法，该分类开销也非常昂贵。

但是，在2D上下文中，这种深度排序问题通常变得毫无意义。 2D上下文通常可以简单地通过开发人员要求绘制事物的顺序来产生所需的结果。 2D元素通常还具有恒定的深度（其深度不随每个片段变化），因此它不会与按像素/片段进行渲染的其他元素的深度相交/重叠。

不到理想的世界

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

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

例如，有可能，如果要渲染的透明前景元素后面有静态背景，则这种不理想的实现可能比处理背景要多得多（以及更多）。理想情况下应该如此。浏览器必须处理涉及客户端脚本和小程序的动态世界，在这些世界中，图形可能会基于无限可能的条件而发生更改。

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

在更简单的级别上，alpha混合多层确实需要检查每一层的内存。如果您说，即使Alpha混合过程只需要合成少量像素，Alpha甚至可以在大量图像上混合很小的透明元素，但它仍必须移动该大量图像的内存部分（没有在这种情况下，在整个扫描线中具有很好的引用局部性）从较慢的内存区域一直到高速缓存层次结构一直到寄存器*。取决于此合成过程必须多久发生一次以及浏览器正在缓冲多少以减少此频率，它可能会成为一个严重的瓶颈。

*为简单起见，我将避免不进行缓存就直接进入流式装载/存储-不论哪种情况，通常都会存在相同的内存趋势。

如果遇到这种情况，解决该问题的一种非常通用的方法是使复合材料中涉及的层更便宜。例如，史诗般的背景图像可以分解为缝合在一起的较小图像，只有特定的较小图像需要合成。即使通常在逐像素的基础上进行相同数量的工作以将这两个元素复合在一起*，也可以提高缓存的局部性。

*在计算中，一个常见的误解是，执行相同数量的工作，甚至执行相同的指令，将产生相同的成本。动态的硬件和操作系统因素使许多指令具有可变的成本，其中最值得注意的是硬件将内存从较大但较慢的类型的内存移动到较快，较小的类型的内存以及软件背后的本质。开发人员的后背。

滚动和加载


  呈现纯色和纯色时的性能差异是什么？
  透明的颜色。当loading和scrolling网页时。


同样，alpha混合非常便宜。但是，透明元素可能会破坏一些不理想实现的浏览器可以对不透明元素进行的潜在优化。与加载相比，这更可能在滚动中显示出来（因为加载只需发生一次）。

结论

简而言之，就此问题而言，alpha混合过程本身非常便宜。要使其成为一个问题，通常需要混合数百万个像素才能开始显示，这是可能要担心的事情。

但是，为了将像素融合在一起而涉及的辅助过程，尤其是在那些现实的，不理想的实现中，可能会开始变得昂贵。不幸的是，在不知道特定浏览器的实现的情况下，不可能对这些进行精确的分类，但是以上这些要点应涵盖许多广泛的可能性。