为了让读者对嵌入式Ｌｉｎｕｘ当中能够使用的图形及图形用户界面有个较为全面的认识，本文将为读者介绍一些嵌入式Ｌｉｎｕｘ系统中常见的图形及图形用户界面系统，并作为＂基于Ｌｉｎｕｘ和ＭｉｎｉＧＵＩ的嵌入式系统软件开发指南＂系列的最后一篇文章。本文首先概述了Ｌｉｎｕｘ图形领域的基本设施，然后描述了一些可供嵌入式Ｌｉｎｕｘ系统使用的高级图形库以及图形用户界面支持系统，并大概比较了这些系统的优缺点。希望能对嵌入式Ｌｉｎｕｘ系统的开发有所帮助。

１Ｌｉｎｕｘ图形领域的基础设施

本小节首先向读者描述Ｌｉｎｕｘ图形领域中常见的基础设施。之所以称为基础设施，是因为这些系统（或者函数库），一般作为其他高级图形或者图形应用程序的基本函数库。这些系统（或者函数库）包括：ＸＷｉｎｄｏｗ、ＳＶＧＡＬｉｂ、ＦｒａｍｅＢｕｆｆｅｒ等等。

１．１ＸＷｉｎｄｏｗ

提起Ｌｉｎｕｘ上的图形，许多人首先想到的是ＸＷｉｎｄｏｗ。这一系统是目前类ＵＮＩＸ系统中处于控制地位的桌面图形系统。无疑，ＸＷｉｎｄｏｗ作为一个图形环境是成功的，它上面运行着包括ＣＡＤ建模工具和办公套件在内的大量应用程序。但必须看到的是，由于ＸＷｉｎｄｏｗ在体系接口上的原因，限制了其对游戏、多媒体的支持能力。用户在ＸＷｉｎｄｏｗ上运行ＶＣＤ播放器，或者运行一些大型的三维游戏时，经常会发现同样的硬件配置，却不能获得和Ｗｉｎｄｏｗｓ操作系统一样的图形效果――即使使用了加速的ＸＳｅｒｖｅｒ，其效果也不能令人满意。另外，大型的应用程序（比如Ｍｏｚｉｌｌａ浏览器）在ＸＷｉｎｄｏｗ上运行时的响应能力，也相当不能令人满意。当然，这里有Ｌｉｎｕｘ内核在进程调度上的问题，也有ＸＷｉｎｄｏｗ的原因。

ＸＷｉｎｄｏｗ为了满足对游戏、多媒体等应用对图形加速能力的要求，提供了ＤＧＡ（直接图形访问）扩展，通过该扩展，应用程序可以在全屏模式下直接访问显示卡的帧缓冲区，并能够提供对某些加速功能的支持。

Ｔｉｎｙ－Ｘ是ＸＳｅｒｖｅｒ在嵌入式系统的小巧实现，它由Ｘｆｒｅｅ８６ＣｏｒｅＴｅａｍ的ＫｅｉｔｈＰａｃｋａｒｄ开发。它的目标是运行于小内存系统环境。典型的运行于Ｘ８６ＣＰＵ上的Ｔｉｎｙ－ＸＳｅｒｖｅｒ尺寸接近（小于）１ＭＢ。

１．２ＳＶＧＡＬｉｂ

ＳＶＧＡＬｉｂ是Ｌｉｎｕｘ系统中最早出现的非Ｘ图形支持库。这个库从最初对标准ＶＧＡ兼容芯片的支持开始，一直发展到对老式ＳＶＧＡ芯片的支持以及对现今流行的高级视频芯片的支持。它为用户提供了在控制台上进行图形编程的接口，使用户可以在ＰＣ兼容系统上方便地获得图形支持。但该系统有如下不足：

接口杂乱。ＳＶＧＡＬｉｂ从最初的ｖｇａｌｉｂ发展而来，保留了老系统的许多接口，而这些接口却不能良好地迎合新显示芯片的图形能力。

未能较好地隐藏硬件细节。许多操作，不能自动使用显示芯片的加速能力支持。

可移植性差。ＳＶＧＡＬｉｂ目前只能运行在ｘ８６平台上，对其他平台的支持能力较差（Ａｌｐｈａ平台除外）。

发展缓慢，有被其他图形库取代的可能。ＳＶＧＡＬｉｂ作为一个老的图形支持库，目前的应用范围越来越小，尤其在Ｌｉｎｕｘ内核增加了ＦｒａｍｅＢｕｆｆｅｒ驱动支持之后，有逐渐被其他图形库替代的迹象。

对应用的支持能力较差。ＳＶＡＧＬｉｂ作为一个图形库，对高级图形功能的支持，比如直线和曲线等等，却不能令人满意。尽管ＳＶＧＡＬｉｂ有许多缺点，但ＳＶＧＡＬｉｂ经常被其他图形库用来初始化特定芯片的显示模式，并获得映射到进程地址空间的线性显示内存首地址（即帧缓冲区），而其他的接口却很少用到。另外，ＳＶＧＡＬｉｂ中所包含的诸如键盘、鼠标和游戏杆的接口，也很少被其他应用程序所使用。

因此，ＳＶＧＡＬｉｂ的使用越来越少，笔者也不建议用户使用这个图形库。当然，如果用户的显示卡只支持标准ＶＧＡ模式，则ＳＶＧＡＬｉｂ还是比较好的选择。

１．３ＦｒａｍｅＢｕｆｆｅｒ

ＦｒａｍｅＢｕｆｆｅｒ是出现在２．２．ｘｘ内核当中的一种驱动程序接口。这种接口将显示设备抽象为帧缓冲区。用户可以将它看成是显示内存的一个映像，将其映射到进程地址空间之后，就可以直接进行读写操作，而写操作可以立即反应在屏幕上。该驱动程序的设备文件一般是／ｄｅｖ／ｆｂ０、／ｄｅｖ／ｆｂ１等等。比如，假设现在的显示模式是１０２４ｘ７６８－８位色，则可以通过如下的命令清空屏幕：

￥ｄｄｉｆ＝／ｄｅｖ／ｚｅｒｏｏｆ＝／ｄｅｖ／ｆｂ０ｂｓ＝１０２４ｃｏｕｎｔ＝７６８

在应用程序中，一般通过将ＦｒａｍｅＢｕｆｆｅｒ设备映射到进程地址空间的方式使用，比如下面的程序就打开／ｄｅｖ／ｆｂ０设备，并通过ｍｍａｐ系统调用进行地址映射，随后用ｍｅｍｓｅｔ将屏幕清空（这里假设显示模式是１０２４ｘ７６８－８位色模式，线性内存模式）：

ｉｎｔｆｂ；

ｕｎｓｉｇｎｅｄｃｈａｒ＊ｆｂ＿ｍｅｍ；

ｆｂ＝ｏｐｅｎ（＂／ｄｅｖ／ｆｂ０＂，Ｏ＿ＲＤＷＲ）；

ｆｂ＿ｍｅｍ＝ｍｍａｐ（ＮＵＬＬ，１０２４＊７６８，ＰＲＯＴ＿ＲＥＡＤ｜ＰＲＯＴ＿ＷＲＩＴＥ，ＭＡＰ＿ＳＨＡＲＥＤ，ｆｂ，０）；

ｍｅｍｓｅｔ（ｆｂ＿ｍｅｍ，０，１０２４＊７６８）；

ＦｒａｍｅＢｕｆｆｅｒ设备还提供了若干ｉｏｃｔｌ命令，通过这些命令，可以获得显示设备的一些固定信息（比如显示内存大小）、与显示模式相关的可变信息（比如分辨率、象素结构、每扫描线的字节宽度），以及伪彩色模式下的调色板信息等等。

通过ＦｒａｍｅＢｕｆｆｅｒ设备，还可以获得当前内核所支持的加速显示卡的类型（通过固定信息得到），这种类型通常是和特定显示芯片相关的。比如目前最新的内核（２．４．９）中，就包含有对Ｓ３、Ｍａｔｒｏｘ、ｎＶｉｄｉａ、３Ｄｆｘ等等流行显示芯片的加速支持。在获得了加速芯片类型之后，应用程序就可以将ＰＣＩ设备的内存Ｉ／Ｏ（ｍｅｍｉｏ）映射到进程的地址空间。这些ｍｅｍｉｏ一般是用来控制显示卡的寄存器，通过对这些寄存器的操作，应用程序就可以控制特定显卡的加速功能。

ＰＣＩ设备可以将自己的控制寄存器映射到物理内存空间，而后，对这些控制寄存器的访问，给变成了对物理内存的访问。因此，这些寄存器又被称为＂ｍｅｍｉｏ＂。一旦被映射到物理内存，Ｌｉｎｕｘ的普通进程就可以通过ｍｍａｐ将这些内存Ｉ／Ｏ映射到进程地址空间，这样就可以直接访问这些寄存器了。

当然，因为不同的显示芯片具有不同的加速能力，对ｍｅｍｉｏ的使用和定义也各自不同，这时，就需要针对加速芯片的不同类型来编写实现不同的加速功能。比如大多数芯片都提供了对矩形填充的硬件加速支持，但不同的芯片实现方式不同，这时，就需要针对不同的芯片类型编写不同的用来完成填充矩形的函数。

说到这里，读者可能已经意识到ＦｒａｍｅＢｕｆｆｅｒ只是一个提供显示内存和显示芯片寄存器从物理内存映射到进程地址空间中的设备。所以，对于应用程序而言，如果希望在ＦｒａｍｅＢｕｆｆｅｒ之上进行图形编程，还需要完成其他许多工作。举个例子来讲，ＦｒａｍｅＢｕｆｆｅｒ就像一张画布，使用什么样子的画笔，如何画画，还需要你自己动手完成。

１．４ＬｉｂＧＧＩ

ＬｉｂＧＧＩ试图建立一个一般性的图形接口，而这个抽象接口连同相关的输入（鼠标、键盘、游戏杆等）抽象接口一起，可以方便地运行在ＸＷｉｎｄｏｗ、ＳＶＧＡＬｉｂ、ＦｒａｍｅＢｕｆｆｅｒ等等之上。建立在ＬｉｂＧＧＩ之上的应用程序，不经重新编译，就可以在上述这些底层图形接口上运行。但不知何故，ＬｉｂＧＧＩ的发展几乎停滞。

２Ｌｉｎｕｘ图形领域的高级函数库

２．１Ｘｌｉｂ及其他相关函数库

在ＸＷｉｎｄｏｗ系统中进行图形编程时，可以选择直接使用Ｘｌｉｂ。Ｘｌｉｂ实际是对底层Ｘ协议的封装，可通过该函数库进行一般的图形输出。如果你的ＸＳｅｒｖｅｒ支持ＤＧＡ，则可以通过ＤＧＡ扩展直接访问显示设备，从而获得加速支持。对一般用户而言，由于Ｘｌｉｂ的接口太原始而且复杂，因此一般的图形程序选择其他高级一些的图形库作为基础。比如，ＧＴＫ、ＱＴ等等。这两个函数同时还是一些高级的图形用户界面支持函数库。由于种种原因，ＧＴＫ、ＱＴ等函数库存在有庞大、占用系统资源多的问题，不太适合在嵌入式系统中使用。这时，你可以选择使用ＦＬＴＫ，这是一个轻量级的图形函数库，但它的主要功能集中在用户界面上，提供了较为丰富的控件集。

２．２ＳＤＬ

ＳＤＬ（ＳｉｍｐｌｅＤｉｒｅｃｔＭｅｄｉａＬａｙｅｒ）是一个跨平台的多媒体游戏支持库。其中包含了对图形、声音、游戏杆、线程等等的支持，目前可以运行在许多平台上，其中包括ＸＷｉｎｄｏｗ、ＸＷｉｎｄｏｗｗｉｔｈＤＧＡ、ＬｉｎｕｘＦｒａｍｅＢｕｆｆｅｒ控制台、ＬｉｎｕｘＳＶＧＡＬｉｂ，以及ＷｉｎｄｏｗｓＤｉｒｅｃｔＸ、ＢｅＯＳ等等。

因为ＳＤＬ专门为游戏和多媒体应用而设计开发，所以它对图形的支持非常优秀，尤其是高级图形能力，比如Ａｌｐｈａ混和、透明处理、ＹＵＶ覆盖、Ｇａｍｍａ校正等等。而且在ＳＤＬ环境中能够非常方便地加载支持ＯｐｅｎＧＬ的Ｍｅｓａ库，从而提供对二维和三维图形的支持。

可以说，ＳＤＬ是编写跨平台游戏和多媒体应用的最佳平台，也的确得到了广泛应用。相关信息，可参阅ｈｔｔｐ：／／ｗｗｗ．ｌｉｂｓｄｌ．ｏｒｇ。

２．３Ａｌｌｅｇｒｏ

Ａｌｌｅｇｒｏ是一个专门为ｘ８６平台设计的游戏图形库。最初的Ａｌｌｅｇｒｏ运行在ＤＯＳ环境下，而目前可运行在ＬｉｎｕｘＦｒａｍｅＢｕｆｆｅ控制台、ＬｉｎｕｘＳＶＧＡＬｉｂ、ＸＷｉｎｄｏｗ等系统上。Ａｌｌｅｇｒｏ提供了一些丰富的图形功能，包括矩形填充和样条曲线生成等等，而且具有较好的三维图形显示能力。由于Ａｌｌｅｇｒｏ的许多关键代码是采用汇编编写的，所以该函数库具有运行速度快、资源占用少的特点。然而，Ａｌｌｅｇｒｏ也存在如下缺点：

对线程的支持较差。Ａｌｌｅｇｒｏ的许多函数是非线程安全的，不能同时在两个以上的线程中使用。

对硬件加速能力的支持不足，在设计上没有为硬件加速提供接口。

有关Ａｌｌｅｇｒｏ的进一步信息，可参阅ｈｔｔｐ：／／ｗｗｗ．ａｌｌｅｇｒｏ．ｃｃ／。

２．４Ｍｅｓａ３Ｄ

Ｍｅｓａ３Ｄ是一个兼容ＯｐｅｎＧＬ规范的开放源码函数库，是目前Ｌｉｎｕｘ上提供专业三维图形支持的惟一选择。Ｍｅｓａ３Ｄ同时也是一个跨平台的函数库，能够运行在ＸＷｉｎｄｏｗ、ＸＷｉｎｄｏｗｗｉｔｈＤＧＡ、ＢｅＯＳ、ＬｉｎｕｘＳＶＧＡＬｉｂ等平台上。

有关Ｍｅｓａ３Ｄ的进一步信息，可参阅ｈｔｔｐ：／／ｗｗｗ．ｍｅｓａ３ｄ．ｏｒｇ／。

２．５ＤｉｒｅｃｔＦＢ

ＤｉｒｅｃｔＦＢ是专注于ＬｉｎｕｘＦｒａｍｅＢｕｆｆｅｒ加速的一个图形库，并试图建立一个兼容ＧＴＫ的嵌入式ＧＵＩ系统。它以可装载函数库的形势提供对加速ＦｒａｍｅＢｕｆｆｅｒ驱动程序的支持。目前，该函数库正在开发之中（最新版本０．９．９７），详情可见ｈｔｔｐ：／／ｗｗｗ．ｄｉｒｅｃｔｆｂ．ｏｒｇ／。

３面向嵌入式Ｌｉｎｕｘ系统的图形用户界面

３．１ＭｉｃｏｒｏＷｉｎｄｏｗｓ／ＮａｎｏＸ

ＭｉｃｒｏＷｉｎｄｏｗｓ（ｈｔｔｐ：／／ｍｉｃｒｏｗｉｎｄｏｗｓ．ｃｅｎｓｏｆｔ．ｃｏｍ）是一个开放源码的项目，目前由美国ＣｅｎｔｕｒｙＳｏｆｔｗａｒｅ公司主持开发。该项目的开发一度非常活跃，国内也有人参与了其中的开发，并编写了ＧＢ２３１２等字符集的支持。但在Ｑｔ／Ｅｍｂｅｄｄｅｄ发布以来，该项目变得不太活跃，并长时间停留在０．８９Ｐｒｅ７版本。可以说，以开放源码形势发展的ＭｉｃｒｏＷｉｎｄｏｗｓ项目，基本停滞。

ＭｉｃｒｏＷｉｎｄｏｗｓ是一个基于典型客户／服务器体系结构的ＧＵＩ系统，基本分为三层。最底层是面向图形输出和键盘、鼠标或触摸屏的驱动程序；中间层提供底层硬件的抽象接口，并进行窗口管理；最高层分别提供兼容于ＸＷｉｎｄｏｗ和ＷｉｎｄｏｗｓＣＥ（Ｗｉｎ３２子集）的ＡＰＩ。

该项目的主要特色在于提供了类似Ｘ的客户／服务器体系结构，并提供了相对完善的图形功能，包括一些高级的功能，比如Ａｌｐｈａ混合，三维支持，ＴｒｕｅＴｙｐｅ字体支持等。但需要注意的是，ＭｉｃｒｏＷｉｎｄｏｗｓ的图形引擎存在许多问题，可以归纳如下：

无任何硬件加速能力。

图形引擎中存在许多低效算法，同时未经任何优化。比如在直线或者圆弧绘图函数中，存在低效的逐点判断剪切的问题。

代码质量较差。由于该项目缺少一个强有力的核心代码维护人员，因此代码质量参差不齐，影响整体系统稳定性。这也是ＭｉｃｒｏＷｉｎｄｏｗｓ长时间停留在０．８９Ｐｒｅ７版本上的原因。

ＭｉｃｒｏＷｉｎｄｏｗｓ采用ＭＰＬ条款发布（该条款基本类似ＬＧＰＬ条款）。

３．２ＯｐｅｎＧＵＩ

ＯｐｅｎＧＵＩ（ｈｔｔｐ：／／ｗｗｗ．ｔｕｔｏｋ．ｓｋ／ｆａｓｔｇｌ／）在Ｌｉｎｕｘ系统上存在已经很长时间了。最初的名字叫ＦａｓｔＧＬ，只支持２５６色的线性显存模式，但目前也支持其他显示模式，并且支持多种操作系统平台，比如ＭＳ－ＤＯＳ、ＱＮＸ和Ｌｉｎｕｘ等等，不过目前只支持ｘ８６硬件平台。ＯｐｅｎＧＵＩ也分为三层。最低层是由汇编编写的快速图形引擎；中间层提供了图形绘制ＡＰＩ，包括线条、矩形、圆弧等，并且兼容于Ｂｏｒｌａｎｄ的ＢＧＩＡＰＩ。第三层用Ｃ＋＋编写，提供了完整的ＧＵＩ对象集。

ＯｐｅｎＧＵＩ采用ＬＧＰＬ条款发布。ＯｐｅｎＧＵＩ比较适合于基于ｘ８６平台的实时系统，可移植性稍差，目前的发展也基本停滞。

３．３Ｑｔ／Ｅｍｂｅｄｄｅｄ

Ｑｔ／Ｅｍｂｅｄｄｅｄ是著名的Ｑｔ库开发商ＴｒｏｌｌＴｅｃｈ（ｈｔｔｐ：／／ｗｗｗ．ｔｒｏｌｌｔｅｃｈ．ｃｏｍ／）发布的面向嵌入式系统的Ｑｔ版本。因为Ｑｔ是ＫＤＥ等项目使用的ＧＵＩ支持库，所以有许多基于Ｑｔ的ＸＷｉｎｄｏｗ程序可以非常方便地移植到Ｑｔ／Ｅｍｂｅｄｄｅｄ版本上。因此，自从Ｑｔ／Ｅｍｂｅｄｄｅｄ以ＧＰＬ条款形势发布以来，就有大量的嵌入式Ｌｉｎｕｘ开发商转到了Ｑｔ／Ｅｍｂｅｄｄｅｄ系统上。比如韩国的Ｍｉｚｉ公司，台湾省的某些嵌入式Ｌｉｎｕｘ应用开发商等等。

不过，在笔者看来，Ｑｔ／Ｅｍｂｅｄｄｅｄ还有一些问题值得开发者注意：

目前，该系统采用两种条款发布，其中包括ＧＰＬ条款。对函数库使用ＧＰＬ条款，意味着其上的应用需要遵循ＧＰＬ条款。当然了，如果要开发商业程序，ＴｒｏｌｌＴｅｃｈ也允许你采用另外一个授权条款，这时，就必须向ＴｒｏｌｌＴｅｃｈ交纳授权费用了。

Ｑｔ／Ｅｍｂｅｄｄｅｄ是一个Ｃ＋＋函数库，尽管Ｑｔ／Ｅｍｂｅｄｄｅｄ声称可以裁剪到最少６３０Ｋ，但这时的Ｑｔ／Ｅｍｂｅｄｄｅｄ库已经基本上失去了使用价值。低的程序效率、大的资源消耗也对运行Ｑｔ／Ｅｍｂｅｄｄｅｄ的硬件提出了更高的要求。

Ｑｔ／Ｅｍｂｅｄｄｅｄ库目前主要针对手持式信息终端，因为对硬件加速支持的匮乏，很难应用到对图形速度、功能和效率要求较高的嵌入式系统当中，比如机顶盒、游戏终端等等。

Ｑｔ／Ｅｍｂｅｄｄｅｄ提供的控件集风格沿用了ＰＣ风格，并不太适合许多手持设备的操作要求。

Ｑｔ／Ｅｍｂｅｄｄｅｄ的结构过于复杂，很难进行底层的扩充、定制和移植，尤其是那个用来实现ｓｉｇｎａｌ／ｓｌｏｔ机制的著名的ｍｏｃ文件。

因为上述这些原因，目前所见到的Ｑｔ／Ｅｍｂｅｄｄｅｄ的运行环境，几乎是清一色基于ＳｔｒｏｎｇＡＲＭ的ｉＰＡＱ。

３．４ＭｉｎｉＧＵＩ

ＭｉｎｉＧＵＩ（ｈｔｔｐ：／／ｗｗｗ．ｍｉｎｉｇｕｉ．ｏｒｇ）是由笔者主持，并由许多自由软件开发人员支持的一个自由软件项目（遵循ＬＧＰＬ条款发布），其目标是为基于Ｌｉｎｕｘ的实时嵌入式系统提供一个轻量级的图形用户界面支持系统。该项目自１９９８年底开始到现在，已历经３年多的开发过程。到目前为止，已经非常成熟和稳定。目前，我们已经正式发布了稳定版本１．０．９，并且开始了新版本系列的开发，即ＭｉｎｉＧＵＩＶｅｒｓｉｏｎ１．１．ｘ，该系列的正式版也即将发布。

在ＭｉｎｉＧＵＩ几年的发展过程中，有许多值得一提的技术创新点，正是由于这些技术上的创新，才使得ＭｉｎｉＧＵＩ更加适合实时嵌入式系统；而且ＭｉｎｉＧＵＩ的灵活性非常好，可以应用在包括手持设备、机顶盒、游戏终端等等在内的各种高端或者低端的嵌入式系统当中。这些技术创新包括：

图形抽象层。图形抽象层对顶层ＡＰＩ基本没有影响，但大大方便了ＭｉｎｉＧＵＩ应用程序的移植、调试等工作。目前包含三个图形引擎，ＳＶＧＡＬｉｂ、ＬｉｂＧＧＩ以及直接基于ＬｉｎｕｘＦｒａｍｅＢｕｆｆｅｒ的ＮａｔｉｖｅＥｎｇｉｎｅ，利用ＬｉｂＧＧＩ时，可在ＸＷｉｎｄｏｗ上运行ＭｉｎｉＧＵＩ应用程序，并可非常方便地进行调试。与图形抽象层相关的还有输入事件的抽象层。ＭｉｎｉＧＵＩ现在已经被证明能够在基于ＡＲＭ、ＭＩＰＳ、ＳｔｒｏｎｇＡＲＭ以及ＰｏｗｅｒＰＣ等的嵌入式系统上流畅运行。

多字体和多字符集支持。这部分通过设备上下文（ＤＣ）的逻辑字体（ＬＯＧＦＯＮＴ）实现，不管是字体类型还是字符集，都可以非常方便地进行扩充。应用程序在启动时，可切换系统字符集，比如ＧＢ、ＢＩＧ５、ＥＵＣＫＲ、ＵＪＩＳ。利用ＤｒａｗＴｅｘｔ等函数时，可通过指定字体而获得其他字符集支持。对于一个窗口来说，同时显示不同语种的文字是可能的。ＭｉｎｉＧＵＩ的这种字符集支持不同于传统通过ＵＮＩＣＯＤＥ实现的多字符集支持，这种实现更加适合于嵌入式系统。

两个不同架构的版本。最初的ＭｉｎｉＧＵＩ运行在ＰＴｈｒｅａｄ库之上，这个版本适合于功能单一的嵌入式系统，但存在系统健壮性不够的缺点。在０．９．９８版本中，我们引入了ＭｉｎｉＧＵＩ－Ｌｉｔｅ版本，这个版本在提高系统健壮性的同时，通过一系列创新途径，避免了传统Ｃ／Ｓ结构的弱点，为功能复杂的嵌入式系统提供了一个高效、稳定的ＧＵＩ系统。

在ＭｉｎｉＧＵＩ１．１．０版本的开发中，我们参照ＳＤＬ和Ａｌｌｅｇｒｏ的图形部分，重新设计了图形抽象层，并增强了图形功能，同时增强了ＭｉｎｉＧＵＩ－Ｌｉｔｅ版本的某些特性。这些特性包括：

ＭｉｎｉＧＵＩ－Ｌｉｔｅ支持层的概念。同一层可容纳多个能够同时显示的客户程序，并平铺在屏幕上显示。

新的ＧＡＬ能够支持硬件加速能力，并能够充分使用显示内存；新ＧＡＬ之上的新ＧＤＩ接口得到进一步增强。新的ＧＤＩ接口可以支持Ａｌｐｈａ混和、透明位块传输、光栅操作、ＹＵＶ覆盖、Ｇａｍｍａ校正，以及高级图形功能（椭圆、多边形、样条曲线）等等。

ＭｉｎｉＧＵＩ新版本在图形方面的增强和提高，将大大扩展它的应用领域，希望能够对嵌入式Ｌｉｎｕｘ上的多媒体应用、游戏开发提供支持。

纵观嵌入式Ｌｉｎｕｘ系统上的各种图形系统方案，我们发现，许多图形系统（如Ｑｔ／Ｅｍｂｅｄｄｅｄ和ＭｉｃｏｒｏＷｉｎｄｏｗｓ），只注重手持设备上的需求，却不太注重其他应用领域的需求，而其他许多需要图形支持的嵌入式Ｌｉｎｕｘ系统却需要许多独特的、高级的图形功能，而不仅仅是图形用户界面。为此，在接下来的开发中，我们还将在如下领域继续开发ＭｉｎｉＧＵＩ：

提供运行在ＭｉｎｉＧＵＩ上的ＪＡＶＡ虚拟机ＡＷＴ组件的实现。

提供ＭｉｎｉＧＵＩ上的ＯｐｅｎＧＬ实现。

提供类ＱＴ控件集的Ｃ＋＋封装。

提供窗口／控件风格主题支持。

在ＭｉｎｉＧＵＩ－Ｌｉｔｅ当中增加对矢量字体的支持。

４小结

综上所述，笔者认为在嵌入式Ｌｉｎｕｘ图形领域，还有许多有待开发人员仔细研究和解决的问题。ＭｉｎｉＧＵＩ的新的发展，也正源于对这些需求的认识之上。我们也衷心希望能够有更多的自由软件开发人员加盟ＭｉｎｉＧＵＩ的开发，一同开发新的嵌入式Ｌｉｎｕｘ的图形系统。