嵌入式Linux图形系统

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

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

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

　　１．１　Ｘ　Ｗｉｎｄｏｗ

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

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

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

　　１．２　ＳＶＧＡＬｉｂ

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

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

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

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

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

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

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

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

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

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

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

　　ｉｎｔ　ｆｂ；

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

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

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

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

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

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

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

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

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

　　１．４　ＬｉｂＧＧＩ

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

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

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

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

　　２．２　ＳＤＬ

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

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

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

　　２．３　Ａｌｌｅｇｒｏ

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

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

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

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

　　２．４　Ｍｅｓａ３Ｄ

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

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

　　２．５　ＤｉｒｅｃｔＦＢ

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

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

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

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

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

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

　　无任何硬件加速能力。

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

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

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

　　３．２　ＯｐｅｎＧＵＩ

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

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

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

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

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

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

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

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

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

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

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

　　３．４　ＭｉｎｉＧＵＩ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　４　小结

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

　　请登陆: 维库电子市场网（www.dzsc.com） 浏览更多信息