Don't Alpha That Pixel! - 1504020523

video_screenshot

视频发布时间

2014年6月25日

视频介绍

Rendering content with alpha blending is a common practice for apps and games across web and mobile. But this visual technique does not come for free! In this talk, we will cover the difference between alpha blending/ alpha testing , how each one effects your content pipeline, and peel back the layers to see the performance differences in these techniques on various types of mobile hardware. Alpha isn't free, and as a developer, maximizing every pixel for performance can make a day and night difference in the look and feel of your app. #perfmatters

视频推介语

暂无，待补充。

译者信息

翻译	润稿	终审	原始链接	中文字幕	翻译流水号	加入字幕组
任皓	伍文其	程路	Youtube	Youtube	1504020523	加入 GDG 字幕组

解说词中文版：

如果你在手机上运行2D游戏

可能你会非常关心渲染的性能

但是最大的性能问题

可能来自于一个古怪的组合 α混合 两个带有透明图层的图像通道混合的透明度计算

过度绘制和如何创造你的纹理贴图集 多张位图拼成一张使得一次缓存读取搞定 可以节约内存

我们从第一个开始

现代2D游戏充斥着精彩的图像

来为场景制造视觉效果

但是当你开始分解它时

你意识到绘制你的环境这件事情

实际上是一场复杂的舞蹈

包含着多个图像层

例如 背景层 地面信息

（动画）精灵 最后 UI数据

时不时的我们会发现

一些对形成最终场景起不到作用的

奇怪的额外的层会出现

实际上这些额外的绘制

浪费了很多性能

而这些性能在移动平台上是弥足珍贵的资源

可以看到实际上有两种

如何渲染图像和场景的办法

一种是按照从后到前的顺序

先绘制远离摄像机的地方的几何图形

再绘制靠近摄像机的地方的几何图形

最后的结果是最后绘制的像素

最靠近摄像机

另一种是从前到后的次序

首先绘制靠近摄像机的图像

然后逐渐的向远方前进

尽管两种技术的渲染顺序

产生相同的像素颜色

从后到前导致了对最终结果毫无用处的

2倍工作量

我们常称之为 过度绘制

性能不同的原因源自于

现代图形API工作的方法

你看OpenGL ES（嵌入系统用）和所有它的桌面兄弟版本（OpenGL）

支持一种叫深度测试的模式

好处是让你避免处理一些像素

这些像素对产生最终图像无用

它是如何工作的

当屏幕上的某个像素被更新了颜色信息时

它距离摄像机的深度也被存储 （就是距离，深度是从垂直于屏幕的Z轴方向去体会的）

当光栅化（像素点绘制器）尝试在屏幕上的同一位置绘制另一个像素

我们首先测试新来的像素点

相对于老像素点的深度

如果新像素点离摄像机更远 那就被直接扔掉

这是节能循环因为不需要计算任何颜色

而如果新来的像素点更靠近摄像机

那就要继续了

计算新像素点的颜色信息 然后写回到颜色缓存中（存放像素点信息的一个或几个缓存）

过度绘制是一个描述

屏幕上的像素在单帧中

被重新绘制多少次的术语

例如 像这样绘制一个大的背景图片

然后在顶层（Z轴方向）绘制一个箱子 它的顶层绘制另一个

然后在顶层放一些字

当你打开分析器的过度绘制模式

你会看到屏幕的一些部分

被处理的次数最多

如果你的屏幕如下面这样红透了

那肯定是有性能问题了

有些像素对最终场景是没有用的 对这些像素做的任何工作

都是浪费时间

对于2D游戏来说α混合是一类

最大的过度绘制源头

一般来说大多数场景

必须在渲染时打开α混合选项

因为那些纹理使用一些

有透明通道的几何图形

当你打开α混合选项在游戏中渲染这些对象时

你被迫只能从后到前渲染你的场景

这是因为在每次绘制中 透明通道操作需要

颜色缓存中已经有像素存在用来混合

这增加了屏幕上已存像素点

被重绘的次数

事实是 你绘制游戏几何图形的顺序（Z轴上）

对你游戏的性能有着深远的影响

理想中 你想要做的是

按照从前向后的顺序绘制所有不透明的几何图形

这样会减少过度绘制发生的总量（因为被前方已绘制的几何图形遮挡的像素点，被计算Z轴深度后可以直接抛弃）

同时按照从后向前的顺序绘制所有含透明度的几何图形

那是为得到想要的样子（前一个像素点的透明部分要和后面那个像素点的透明部分运算）

必须做的（必须先有后面的，再绘制前面的）

但是啊 相信我 说易行难

我读了一篇来自Google Play的1000个游戏的分析

发现其中大多数

把含透明度和不透明图像包到一个纹理贴图集

这是典型的坏主意

用来做这个操作的纹理贴图集软件

并不总是输出每个图像信息的类型

让你能知道哪些原来是含透明度的

哪些原来是不透明的

结果是你不得不假设

场景上所有东西都是含透明度的

忽略这带来的性能问题

按照从前到后的顺序渲染所有东西

为了在你的游戏中改掉这个问题 方法其实很简单

当创建你的贴图集时 区分你的含透明度和不透明

对象到不同纹理

这会让你在运行时基于纹理类型

在渲染几何形状到最终场景之前

排列他们的顺序

新的流程将有助于减少过度绘制

并有助于你的场景渲染的更快

哦还有一件事

一旦你区分了不透明纹理

到他们的贴图集中 确保正确的使用

GP（图形处理器）纹理格式压缩它们

ETC PVR和DXT都被多层次的硬件支持

将会减轻分发量和减少你的纹理

在GPU（图形处理器单元）中占据的尺寸 这是大家都喜欢的 对吧

不管怎样事实是你

不应该对使用α混合掉以轻心

除了达成你想要的样子之外

还有些你可能没有意识到的性能问题的负担

所以三思以后 再想想透明度 然后一如既往 记住 性能问题