本节书摘来异步社区《OpenGL ES 3.x游戏开发（下卷）》一书中的第2章，第2.7节，作者： 吴亚峰 责编： 张涛，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.7 固定渲染管线与可编程渲染管线实现方案的对比
本章最开始提到过，在固定渲染管线平台上想高效地实现本章案例中的特效是非常困难的。这是因为在固定渲染管线中，顶点数据一旦送入渲染管线后就不可能对其方便地自定义处理了。因此，在固定渲染管线上想实现本章案例中的特效只能采用以下两种策略之一。
提示
回顾一下，OpenGL ES 1.x（含1.0和1.1）采用的是固定渲染管线，从OpenGL ES 2.0开始采用可编程渲染管线。
1．初始化时预先计算数据
此种策略的基本思想非常简单，就是在初始化时将动画中每一帧画面的顶点数据都计算出来，绘制每一帧画面时将与此帧画面对应的顶点数据送入渲染管线即可。因此，此策略有两方面明显的局限性。
动画中的帧数不能过多，否则会占用大量的内存，导致程序不能正常执行。由于帧数不是很多，因此对于动态范围大的动画就会不太平滑，效果一般。
动画中的每一帧都是预先计算好的，不能够根据用户交互情况的变化而变化，灵活性差。
2．绘制每帧画面前由CPU临时计算顶点数据
此种策略其实就是将本章案例中由顶点着色器完成的工作改为绘制每帧画面前由CPU来完成，这可以解决第一种策略的两个局限，但它本身也有很大的局限性。因为在这种情况下，CPU一方面需要处理顶点数据，同时还承载了很多处理其他业务逻辑的任务，如人机交互、物理碰撞等，这会导致CPU不堪重负，整个程序运行很慢。
从上述通过固定渲染管线实现本章案例特效可能采用的两种策略中可以看出，基于固定渲染管线很难完全发挥出GPU强大的处理能力，因此，整个3D开发产业现在都在向可编程渲染管线迈进。读者在以后的开发中也可以多思考、多总结，将能够由着色器完成的工作都让着色器去完成，尽量把CPU解放出来。
提示
笔者也是从固定渲染管线走过来的，那时开发的一些高级的特效，一方面代码很长，开发成本高；另一方面，运行速度慢，不得不做出很多牺牲。现在有了可编程渲染管线，原来的很多限制都不复存在了，相信随着硬件的进一步发展，可以开发出更多、更好的3D特效。
