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环境中，如果我们有一百万个半透明多边形要渲染，现在我们必须以深度排序的顺序渲染它们的碎片，以确保一致，正确的结果。即使使用非最佳近似方法（如双深度剥离），分类开销也非常昂贵。

然而，在2D环境中，这种深度排序问题通常没有实际意义。 2D上下文通常只能通过开发人员请求绘制内容的顺序产生所需的结果。 2D元素通常也具有恒定的深度（其深度不会因每个片段而变化），因此它不会与基于每个像素/片段呈现的其他元素的深度相交/重叠。 / p>

不太理想的世界

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

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

例如，如果你在透明前景元素后面有一个静态背景，那么你可能需要渲染，这种不太理想的实现可能需要更频繁地处理背景（还有更多的理由应该比它更多。浏览器必须处理涉及客户端脚本和applet的动态世界，其中图形可能会根据条件的无限可能性而发生变化。

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

在更简单的层面上，alpha混合多个图层确实需要检查每个图层的内存。例如，如果你将alpha混合甚至是一个巨大的图像上的青少年透明元素，即使alpha混合过程只需要合成少量像素，它仍然必须移动这个大尺寸图像的部分内存（这不是＆＃39; t在扫描线的这个上下文中具有非常好的引用局部性，从存储器的缓慢区域一直到缓存层次结构并进入寄存器*。根据此合成过程发生的频率以及浏览器缓存以减少此频率的程度，它可能成为一个重大瓶颈。

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

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

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

滚动和加载

  

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

同样，alpha混合很便宜。但是，透明元素可能会破坏一些潜在的优化，即不太理想的浏览器可以为不透明元素做出优化。这更有可能出现在滚动而不是加载（因为加载只需要发生一次）。

<强>结论

简而言之，在这个问题的背景下，alpha混合过程本身非常便宜。为了使它成为一个问题，往往需要数百万和几百万像素混合，甚至开始出现可能需要担心的事情。

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