感受Android带给我们的新体验
By: 大庄 | In: OpenGL ES
2 九 2009图例2.1显示了一个GL的大纲图表。GL命令从左边输入。一些命令用于几何图形的绘制,另一些用于控制不同场景中的对象。
第一类场景操作是针对原始几何对象:点、线段和三角形。它们使用顶点来描述。在这个场景中,顶点被转换和限制,原始对象被裁减成一个视图的容量,为下一个场景做准备—栅格化。栅格化构建了一系列的帧缓存地址和值,使用二维描述点、线段、或者三角形。每个片段的创建是为下个场景提供源。在他们最终改变到帧缓存中之前,每个场景作为独立的片段运行。这些操作包括 有条件的更新到帧缓存(该操作基于正在到来和先前保存深度值(影响深度缓存)),混合正在到来的片段颜色和先前保存的颜色,遮照和其他的对片段的逻辑操作。
值可能从帧缓存中被读回,或者复制帧缓存的一部分到另一个帧缓存中去,这些传输可能包含某种类型的编解码。这种分类意味着仅仅使用作为一个工具去描述GL,而不能严格定义GL是如何实现的,我们在这里规定的只是组织各种GL的操作。
GL仅能探测到所有被考虑到的错误的一个子集,这是因为很多情况下,错误的检查 与 一个错误-自由程序的实现 相违背。
命令:
enum GetError(void);
用于获得错误信息,每个可以探测到错误对应的数字码。
当一个错误被探测到,一个标志将被设置,错误码同时被记录。很多些的错误发生后,不会影响那些记录码。当GetError被调用,记录码会被返回,并且错误标志会被清除。所以一个高级的错误可能会导致重复记录它的错误码。如果调用 GetError返回NO_ERROR,表示从上次调用GetError后(或者在GL初始化前),没有发生可被检测到的错误。
考虑到分配的实现,有可能存在几种的错误-标志码对。因此,调用GetError后,返回的值,除了NO_ERROR外,每个随后的调用会返回一个可区分的非零标志码,直到所有的非NO_ERROR被返回。当没有 其他非NO_ERROR错误码后,所有的标志位被重置。这种方案要求一些确切数目的配对(一个比特标志和一个整数)。初始化时,所有标志都被清除,并且所有代码的被初始化为NO_ERROR。
表2.3总结了所有的GL错误。当前,当错误标志被设置,只有当OUT_OF_MEMORY发生时,GL的操作结果未定义。在其他情况下,命令产生的错误被忽略,所以它对当前GL状态或者帧缓存里的内容不产生影响。如果产生的命令返回一个值,它将返回零。如果发生的命令需要修改指针参数传来的值,这些值将不会发生任何改变。这些错误的规定仅应用于GL错误,不应用于系统错误,例如 内存访问错误。这些规定是当前设定的行为,当前GL对错误的行为的定义常常会改变。
在对于每个GL命令描述中,有三个产生错误的条件是绝对的。第一,如果一个命令需要一个文档中未规定的枚举值,是不允许的。INVALID_ENUM 错误会返回。即使参数是一个指向常量的指针,该值不是命令所允许的。使用Common 或者 Common_Lite profiles中的任意一个常量,如果常量仅被其中一种的profiles定义和接受,也可能出现INVALID_ENUM错误。
第二,当一个参数的类型的sizei是特定的,如果提供一个负数作参数,也会导致INVALID_VALUE错误。
最后,如果当一个命令的执行,导致内存耗尽,错误OUT_OF_MEMORY可能产生。除此以外的错误,只有在此文档中描述的情况下才会产生。
| Error | Description | Offending command ignored? |
| INVALID ENUM | enum argument out of range | Yes |
| INVALID VALUE | Numeric argument out of range | Yes |
| INVALID OPERATION | Operation illegal in current state | Yes |
| STACK OVERFLOW | Command would cause a stack
overflow |
Yes |
| STACK UNDERFLOW | Command would cause a stack
underflow |
Yes |
| OUT OF MEMORY | Not enough memory left to exe-
cute command |
Unknown |
Table 2.3:GL错误概要

这里有一群热爱开发的人,我们的文章以原创、翻译为主,包含了我们对Android的认识,对Android的研究,以及一些开发心得和感想,如果 你喜欢我们的站点,喜欢我们的文章,欢迎拍砖,欢迎交流。希望新版的mo-Android能够为你带来更好的体验。