新。OpenGL 3.1将此前引入的OpenGL着色语言“GLSL”从1.30版升级到了1.40版，通过改进程序增强了对最新可编程图形硬件的访问，还有更高效的顶点处理、扩展的纹理功能、更弹性的缓冲管理等等。宽泛地讲，OpenGL 3.1在3.0版的基础上对整个API模型体系进行了简化，可大幅提高软件开发效率。
2009年8月Khronos小组发布了OpenGL 3.2，这是一年以来OpenGL进行的第三次重要升级。该版本仍然延续了OpenGL发展的方向让图形程序开发者能在多种操作系统和平台下更好的利用新的GPU功能。OpenGL3.2版本提升了性能表现、改进了视觉质量、提高了几何图形处理速度，而且使Direct3D程序更容易移植为OpenGL。除OpenGL之外，Khronos还将其开发的其它标准进行了协调改进，以求可以在更广泛的领域提供强大的图形功能和计算生态系统，这些标准包括用于并行计算的OpenCL、用于移动3D图形开发的OpenGL ES和用于网络3D开发的WebGL。
Khronos旗下的OpenGL ARB(Architecture Review Board)工作组推出了GLSL 1.5OpenGLShading Language(OpenGL着色语言)的升级版，以及在OpenGL3.2框架下推出了两个新功能，可以让开发者在开发新程序时能够在使用流水线内核特性或兼容性特性之间做出选择，其中兼容性特性会提供与旧版OpenGL之间的兼容性。 2.2 OpenGL渲染管线
绝大数OpenGL实现都有相似的操作顺序，一系列相关的处理阶段称为OpenGL渲染管线。图1显示了这些顺序，虽然并没有严格规定OpenGL必须采用这样的实现，但它提供了一个可靠的指南，可以预测OpenGL将以什么样的顺序来执行这些操作。
顶点数据 计 算 程 序 Evaluators 逐顶点 操作与 图元装配 光栅化 像素 操作 纹理装配 帧缓存 逐片断操作 显示 列表 像素数据 图1 OpenGL渲染流程
图1显示了Henry Ford在福特汽车公司采用的装配线方法，它也是OpenGL处理数据的方法。几何数据(顶点，直线和多边形)所经历的处理阶段包括求值和基于顶点的操作，而像素数据(像素，图像和位图)的处理过程侧有所不同。在最终的像素数据写入到帧缓冲区之前，这两种类型的数据都将经过相同的最终步骤(光棚化和片断操作)。
下面，详细地介绍OpenGL渲染管线的一些关键阶段： 2.2.1 显示列表
任何数据，不管它所描述的是几何图形还是像素，都可以保存在显示列表(display list)中，供当前或以后使用。当然，我们也可以不把数据保存在显示列表中，而是立即对数据进行处理，这种模式也称为立即模式(immediate mode)。当一个显示列表被执行时，被保存的数据就从显示列表中取出，就像在立即模式下直接由应用程序所发送的那样。 2.2.2 求值器
7
所有的几何图元最终都要通过顶点来描述。参数化曲线和表面最初可能是通过控制点以及成为基函数(Basic function)的多项式函数进行描述的。求职器提供了一种方法。根据控制点计算表示表面的顶点。这种方法是一种多项式映射，它可以根据控制点产生表面法线、纹理坐标、颜色以及空间坐标。
2.2.3 基于顶点的操作
对于顶点数据，接下来的一个步骤就是\基于顶点的操作\，就是把顶点变换为图元。有些类型的顶点数据(例如空间坐标)是通过一个4*4的浮点矩阵进行变换的。空间坐标从3D世界的一个位置投影到屏幕上的一个位置。
如果启用了高级特性，这个阶段将更为忙碌。如果使用了纹理，这个阶段还将生成并变换纹理坐标。如果启用了光照，就需要综合变换后的顶点，表面法线，光源位置，材料属性以及其他光照信息进行光照计算，产生最终的颜色值。 2.2.4 图元装配
图元装配的一个主要内容就是剪裁，它的任务是消除位于半空间(half-space)之外的那部分几何图元，而这个半空间是由一个平面所定义的。点剪裁就是简单地接受或拒绝顶点，直线或多边形剪裁则可能需要添加额外的顶点，具体取决于直线或多边形是如何进行剪裁的。在有些情况下，接下来需要执行一个称为透视除法(perspective division)的步骤。它使远处的物体看起来比近处的物体更小一些。接下来所进行的是视口(viewport)和深度(z坐标)操作。如果启用了剔除功能(culling)并且该图元是个多边形，那么它就有可能被剔除测试所拒绝。取决于多边形模式，多边形可能被画成点的形式或者直线的形式。
这个阶段所产生的结果就是完整的几何图元，也就是根据相关的颜色，深度(有时还有纹理坐标值以及和光棚化处理有关的一些指导信息)进行了变换和剪裁的顶点。 2.2.5 像数操作
在OpenGL的渲染管线中，和单路径的几何数据相比，像素数据所经历的流程有所不同。首先，来自系统内存的一个数组中的像素进行解包，从某种格式(像素的原始格式可能有多种)解包为适当数量的数据成分。接着，这些数据被缩放、偏移，并根据一副像素图进行处理。处理结果先进行截取，然后或者写入到纹理内存，或者发送到光棚化阶段。如果像素数据时从帧缓冲区读取的，就对他们执行像素转换操作(缩放、偏移、映射和截取)。然后，这些结果被包装为一种适当的格式，并返回到系统内存的一个数组中。
OpenGL有一种特殊的像素复制操作，可以把数据从帧缓冲区复制到帧缓冲区的其他位置或纹理内存中。这样，在数据写入到纹理内存或者写回到帧缓冲区之前，只需要进行一道像素转换就可以了。
2.2.6 纹理装配
OpenGL应用程序可以在几何物体上应用纹理图像，使它们看上去更为逼真。如果需要使用多幅纹理图像，把它们放在纹理对象中是一种明智的做法。这样，就可以很方便地在他们之间进行切换。
有些OpenGL实现拥有一些特殊的资源，可以加速纹理的处理。这种资源可能是专用的，高性能的纹理内存。如果确实拥有这种内存，纹理对象可能会优先进行处理，以控制这种有限和宝贵的资源的使用。 2.2.7 光栅化
光棚化就是把几何数据和像素数据转换为片断(fragment)的过程。每个片断方块对应用于帧缓冲区中的一个像素。把顶点连接起来形成直线或者计算填充多边形的内部像素时，需要考虑直线和多边形的点画模式，直线的宽度，点的大小，着色模型以及用于支持抗锯齿处理的覆盖计算。每个片断方块都将具有各自的颜色和深度值。 2.2.8 片段操作
在数据实际存储到帧缓冲区之前， 将要执行一系列的操作。这些操作可能会修改甚至丢弃这些
8
片断。所有这些操作都可以被启用或禁用。
第一个可能执行的操作是纹理处理。在纹理内存中为每个片断生成一个纹理单元(texel，也就是纹理元素)，并应用到这个片断上。接着可能进行的是雾计算，然后是剪裁测试，alpha测试，模板测试和深度缓冲区测试(深度缓冲区用于消除被隐藏的表面)。如果一个片断无法通过一个启用的测试，它的连续处理过程可能会被中断。随后，将要执行的可能是混合，抖动，逻辑操作以及根据一个位掩码的屏蔽操作。最后，经过完整处理的片断就被绘制到适当的缓冲区，最终成为一个像素并到达它的最终目的地。 2.3 MFC
2.3.1 MFC简介
MFC是一个编程框架，目前最新版本为10.0。MFC (Microsoft Foundation Class Library) 中的各种类结合起来构成了一个应用程序框架，它的目的就是让程序员在此基础上来建立Windows下的应用程序，这是一种相对SDK来说更为简单的方法。因此总体上，MFC框架定义了应用程序的轮廓，并提供了用户接口的标准实现方法，程序员所要做的就是通过预定义的接口把具体应用程序特有的东西填入这个轮廓。Microsoft Visual C++提供了相应的工具来完成这个工作：AppWizard可以用来生成初步的框架文件（代码和资源等）；资源编辑器用于帮助直观地设计用户接口；ClassWizard用来协助添加代码到框架文件；最后编译，则通过类库实现了应用程序特定的逻辑。 2.3.2 MFC的发展历程
MFC是在1992年随微软的Microsoft C/C++ 7.0编译器发布的，用于面向16位Windows的软件开发。起初，MFC是作为一个应用程序框架开发的，所以定名为Application FrameworkX (AFX)。
Borland几乎同时发布了面向Turbo C编译器的OWL，并且在一开始比MFC更具有市场占有率，但是在Borland发布了一个不向下兼容的应用程序框架之后，它丧失了很多市场份额；在Borland从微软获得发布MFC的授权之后它的市场份额进一步减少。Borland最终用Visual Component Library来作为OWL的后继者。
随着Visual Basic和Visual Studio .NET的发布，曾经一度被微软重点推荐的MFC被Visual Basic、C#、Windows Forms抢走了不少市场份额，但是MFC继续在非托管软件开发中占据重要地位。在托管开发方面，MFC中也包括对Windows Forms和托管／非托管互操作的封装。微软在Windows Vista和Windows 7发布之后在MFC中增加了对新的Windows API支持。 2.3.3 MFC的特点 1.封装
构成MFC框架的是MFC类库。MFC类库是C++类库。这些类或者封装了Win32应用程序编程接口，或者封装了应用程序的概念，或者封装了OLE特性，或者封装了ODBC和DAO数据访问的功能，等等，分述如下。
（1）对Win32应用程序编程接口的封装
用一个C++ Object来包装一个Windows Object。例如：class CWnd是一个C++ window object，它把Windows window(HWND)和Windows window有关的API函数封装在C++ window object的成员函数内，后者的成员变量m_hWnd就是前者的窗口句柄。 （2）对应用程序概念的封装
使用SDK编写Windows应用程序时，总要定义窗口过程，登记Windows Class，创建窗口，等等。MFC把许多类似的处理封装起来，替程序员完成这些工作。另外，MFC提出了以文档-视图为中心的编程模式，MFC类库封装了对它的支持。文档是用户操作的数据对象，视图是数据操作的窗口，用户通过它处理、查看数据。 （3）对COM/OLE特性的封装
OLE建立在COM模型之上，由于支持OLE的应用程序必须实现一系列的接口（Interface），因而相当繁琐。MFC的OLE类封装了OLE API大量的复杂工作，这些类提供了实现OLE的更高级接口。 （4）对ODBC功能的封装
以少量的能提供与ODBC之间更高级接口的C++类，封装了ODBC API的大量的复杂的工作，提供了一种数据库编程模式。 2.继承
9
首先，MFC抽象出众多类的共同特性，设计出一些基类作为实现其他类的基础。这些类中，最重
要的类是CObject和CCmdTarget。CObject是MFC的根类，绝大多数MFC类是其派生的，包括CCmdTarget。CObject 实现了一些重要的特性，包括动态类信息、动态创建、对象序列化、对程序调试的支持，等等。所有从CObject派生的类都将具备或者可以具备CObject所拥有的特性。CCmdTarget通过封装一些属性和方法，提供了消息处理的架构。MFC中，任何可以处理消息的类都从CCmdTarget派生。
针对每种不同的对象，MFC都设计了一组类对这些对象进行封装，每一组类都有一个基类，从基类派生出众多更具体的类。这些对象包括以下种类：窗口对象，基类是CWnd；应用程序对象，基类是CwinThread；文档对象，基类是Cdocument，等等。 3.虚拟函数和动态约束
MFC以“C++”为基础，自然支持虚拟函数和动态约束。但是作为一个编程框架，有一个问题必须解决：如果仅仅通过虚拟函数来支持动态约束，必然导致虚拟函数表过于臃肿，消耗内存，效率低下。例如，CWnd封装 Windows窗口对象时，每一条Windows消息对应一个成员函数，这些成员函数为派生类所继承。如果这些函数都设计成虚拟函数，由于数量太多，实现起来不现实。于是，MFC建立了消息映射机制，以一种富有效率、便于使用的手段解决消息处理函数的动态约束问题。 2.3.4 MDI（多文档界面）应用程序构成
用AppWizard产生一个MDI工程t（无OLE等支持），AppWizard创建了一系列文件，构成了一个应用程序框架。这些文件分四类：头文件（.h），实现文件(.cpp)，资源文件(.rc)，模块定义文件(.def)，等。
（a）构成应用程序对象
下图解释了该应用程序的结构，箭头表示信息流向。
图 2 MDI应用程序构成
从CWinApp、CDocument、CView、CMDIFrameWnd、CMDIChildWnd类对应地派生出CTApp、CTDoc、CTView、CMainFrame、CChildFrame五个类，这五个类的实例分别是应用程序对象、文档对象、视对象、主框架窗口对象和文档边框窗口对象。主框架窗口包含了视窗口、工具条和状态栏。对这些类或者对象解释如下。 （1）应用程序类
应用程序类派生于CWinApp。基于框架的应用程序必须有且只有一个应用程序对象，它负责应用程序的初始化、运行和结束。 （2）边框窗口类 如果是SDI应用程序，从CFrameWnd类派生边框窗口类，边框窗口的客户子窗口(MDIClient)直接包含视窗口；如果是MDI应用程序，从CMDIFrameWnd类派生边框窗口类，边框窗口的客户子窗口(MDIClient)直接包含文档边框窗口。 如果要支持工具条、状态栏，则派生的边框窗口类还要添加CToolBar和CStatusBar类型的成员变量，以及在一个OnCreate消息处理函数中初始化这两个控制窗口。 边框窗口用来管理文档边框窗口、视窗口、工具条、菜单、加速键等，协调半模式状态（如上下文的帮助(SHIFT+F1模式)和打印预览。 （3）文档边框窗口类
10
文档边框窗口类从CMDIChildWnd类派生，MDI应用程序使用文档边框窗口来包含视窗口。 （4）文档类
文档类从CDocument类派生，用来管理数据，数据的变化、存取都是通过文档实现的。视窗口通过文档对象来访问和更新数据。 （5）视类
视类从CView或它的派生类派生。视和文档联系在一起，在文档和用户之间起中介作用，即视在屏幕上显示文档的内容，并把用户输入转换成对文档的操作。 （6）文档模板类
文档模板类一般不需要派生。MDI应用程序使用多文档模板类CMultiDocTemplate；SDI应用程序使用单文档模板类CSingleDocTemplate。应用程序通过文档模板类对象来管理上述对象（应用程序对象、文档对象、主边框窗口对象、文档边框窗口对象、视对象）的创建。 （b）构成应用程序的对象之间的关系
图3 应用程序的对象之间的关系
用图的形式可直观地表示所涉及的MFC类的继承或者派生关系，如图所示意。 图所示的类都是从CObject类派生出来的；所有处理消息的类都是从CCmdTarget类派生的。如果是多文档应用程序，文档模板使用CMultiDocTemplae，主框架窗口从CMdiFarmeWnd派生，它包含工具条、状态栏和文档框架窗口。文档框架窗口从CMdiChildWnd派生，文档框架窗口包含视，视从CView或其派生类派生。
c） 构成应用程序的文件
通过上述分析，可知AppWizard产生的MDI框架程序的内容，所定义和实现的类。下面，从文件的角度来考察AppWizard生成了的源码和作用。表1列出了AppWizard所生成的头文件，表2列出了了AppWizard所生成的实现文件及其对头文件的包含关系。
表1 AppWizard所生成的头文件 头文件 Stdafx.h resource.h t.h childfrm.h mainfrm.h 用途 标准AFX头文件 定义了各种资源ID #include\定义了从CWinApp派生的应用程序对象CTApp 定义了从CMDIChildWnd派生的文档框架窗口对象CTChildFrame 定义了从CMDIFrameWnd派生的框架窗口对象CMainFrame 11