(一)Linux 图形库
1.1 Linux 图形领域的基础设施
在进行Linux下的图形系统编程时,我们常常会遇到以下这些概念:Framebuffer, X11, SDL,DFB, miniGUI, OpenGL,QT, GTK,KDE, GNOME等等。
1 X Window
X Window从逻辑上分为三层:X Server、X Client和X协议。
最底层的X Server(X服务器)主要处理输入/输出信息并维护相关资源,它接受来自键盘、鼠标的操作并将它交给X Client(X客户端)作出反馈,而由X Client传来的输出信息也由它来负责输出;
最上层的X Client则提供一个完整的GUI界面,负责与用户的直接交互(KDE、GNOME都是一个X Client)。X协议则是衔接X Server与X Client的通讯协议,它的任务是充当这两者的沟通管道。尽管UNIX厂商采用相同的X Window,但终端的X Client并不相同。
XFree86是X Window系统的一个开源的实现。它主要运行于Unix以及类Unix操作系统上。XFree86在显示硬件(鼠标、键盘以及显卡)与桌面环境(也就是窗口管理器)之间提供了一个Client/Server接口。
2 SVGALib
SVGALib是Linux下的底层图形库,也是Linux系统中最早出现的非X图形支持库,它支持标准的VGA图形模式和一些其他的模式,SVGALib的缺点是程序必须以root权限登录,并且它是基于图形卡的,所以不是所有的硬件都支持它。
自从framebuffer这个孪生姐妹诞生后,许多软件由只支持SVGALib变为同时支持两者,甚至一些流行的高层函数库如QT 和GTK只支持Framebuffer,作为一个老的图形支持库,SVGALib目前的应用范围越来越小,尤其是在 Linux 内核增加了FrameBuffer驱动支持之后。
3 FrameBuffer
FrameBuffer是出现在Linux 2.2.xx内核当中的一种驱动程序接口。这种接口将显示设备抽象为帧缓冲区。用户可以将它看成是显示内存的一个映像,将其映射到进程地址空间之后,就可以直接对显存进行读写操作,而写操作可以立即反映在屏幕上。该驱动程序的设备文件一般是/dev/fb0、/dev/fb1 等等。
在应用程序中,一般通过将FrameBuffer设备映射到进程地址空间的方式
来使用,比如下面的程序就打开/dev/fb0设备,并通过mmap系统调用进行地址映射,随后用memset将屏幕清空(这里假设显示模式是1024x766-8位色模式线性内存模式):
FrameBuffer设备还提供了若干ioctl命令,通过这些命令,可以获得显示
设备的一些固定信息(比如显示内存大小)、与显示模式相关的可变信息(比如分辨率、象素结构、每扫描线的字节宽度),以及伪彩色模式下的调色板信息等等。
FrameBuffer 实际上只是一个提供显示内存和显示芯片寄存器从物理内存映
射到进程地址空间中的设备。所以,对于应用程序而言,如果希望在 FrameBuf.
之上进行图形编程,还需要完成其他许多工作。FrameBuffer 就像一张画布,用什么样子的画笔,如何画画,还需要你自己动手完成。
1.2 Linux 图形领域的高级函数库
1 Xlib及其他相关函数库
在X Window系统中进行图形编程时,可以选择直接使用Xlib。Xlib实际上是对底层X协议的封装,可通过该函数库进行一般的图形输出。如果你的X Server支持DGA,则可以通过DGA扩展直接访问显示设备,从而获得加速支持。对一般用户而言,由于Xlib的接口太原始而且复杂,因此一般的图形程序选择其他高级一些的图形库作为基础。比如GTK、QT 等等。这两个函数库同时还是一些高级的图形用户界面的支持函数库。由于种种原因,GTK、QT等函数库存在庞大、占用系统资源多的问题,不太适合在嵌入式系统中使用。这时,你可以选择使用 FLTK,这是一个轻量级的图形函数库,但它的主要功能集中在用户界面上,提供了较为丰富的控件集。
2 SDL
SDL(Simple DirectMedia Layer)是一个跨平台的多媒体游戏支持库。其中包含了对图形、声音、游戏杆、线程等等的支持,目前可以运行在许多平台上,其中包括 X Window、X Window with DGA、Linux FrameBuffer控制台、Linux SVGALib,以及Windows DirectX、BeOS 等等。
因为SDL是专门为游戏和多媒体应用而设计开发,所以它对图形的支持非常优秀,尤其是高级图形能力,比如Alpha混和、透明处理、YUV覆盖、Gamma 校正等等。而且在SDL环境中能够非常方便地加载支持OpenGL的Mesa库,从而提供对二维和三维图形的支持。
可以说,SDL是编写跨平台游戏和多媒体应用的最佳平台,也的确得到了广泛应用。相关信息,可参阅 http://www.libsdl.org/。
3 Allegro
Allegro是一个专门为x86平台设计的游戏图形库。最初的Allegro运行在 DOS环境下,而目前可运行在Linux FrameBuffer控制台、Linux SVGALib、X Window等系统上。Allegro提供了一些丰富的图形功能,包括矩形填充和样条曲线生成等等,而且具有较好的三维图形显示能力。由于Allegro的许多关键代码是采用汇编编写的,所以该函数库具有运行速度快、资源占用少的特点。然而,Allegro也存在如下缺点:
1)对线程的支持较差。Allegro的许多函数是非线程安全的,不能同时在两个以上的线程中使用。
2)对硬件加速能力的支持不足,在设计上没有为硬件加速提供接口。
有关 Allegro 的进一步信息,可参阅http://www.allegro.cc/。
4 Mesa3D
Mesa3D是一个兼容OpenGL规范的开放源码函数库,是目前Linux上提供专业三维图形支持的惟一选择。Mesa3D同时也是一个跨平台的函数库,能够运行在X Window、X Window with DGA、BeOS、Linux SVGALib 等平台上。
有关 Mesa3D 的进一步信息,可参阅 http://www.mesa3d.org/。
5 DirectFB
DirectFB是专注于Linux FrameBuffer硬件加速的一个图形库,并试图建立一个兼容GTK的嵌入式GUI系统。它以可装载函数库的形式提供对加速 FrameBuffer驱动程序的支持。目前,该函数库正在开发之中(最新版本 0.9.97),详情可见 http://www.directfb.org/。
1.3 面向嵌入式Linux系统的图形用户界面
1 OpenGUI
OpenGUI(http://www.tutok.sk/fastgl/)在Linux系统上存在已经很长时间了。最初的名字叫FastGL,只支持256色的线性显存模式,但目前也支持其他显示模式,并且支持多种操作系统平台,比如 MS-DOS、QNX 和Linux等等,不过目前只支持x86硬件平台。OpenGUI也分为三层。最低层是由汇编编写的快速图形引擎;中间层提供了图形绘制API,包括线条、矩形、圆弧等,并且兼容于 Borland的BGI API。第三层用C++编写,提供了完整的GUI对象集。
OpenGUI采用LGPL条款发布。OpenGUI比较适合于基于x86平台的实时系统,可移植性稍差,目前的发展也基本停滞。
2 Qt/Embedded
Qt/Embedde是著名的Qt库开发商TrollTech发布的面向嵌入式系统的Qt版本。因为Qt是KDE等项目使用的GUI支持库,所以有许多基于Qt 的X Window程序可以非常方便地移植到Qt/Embedded版本上。因此,自从Qt/Embedded以GPL条款形势发布以来,就有大量的嵌入式Linux开发商转到了Qt/Embedded系统上。比如韩国的Miz 公司,台湾省的某些嵌入式Linux应用开发商等等。
3.MiniGUI
MiniGUI(http://www.minigui.org/)是由许多自由软件开发人员支持的一个自由软件项目(遵循 LGPL 条款发布),其目标是为基于Linux 的实时嵌入式系统提供一个轻量级的图形用户界面支持系统。
1.4 Linux/Unix系统图形界面GTK、QT、GNOME和KDE的关系
KDE早于Gnome出现,但是KDE基于的Qt是不遵循GPL开源协议的,Qt是一个跨平台的C++图形用户界面库 ,它是挪威TrollTech公司的产品(2008年底被NOKIA收购)。 Qt具有优良的跨平台特性(支持Windows、Linux、各种UNIX、OS390和QNX等)、面向对象机制以及丰富的API,同时也可支持2D/3D渲染和OpenGL API。在当时的同类图形用户界面库产品中,Qt的功能最为强大.但底层的基础 Qt却是一个不遵循GPL的商业软件,这就给KDE上了一道无形的枷锁并带来可能的法律风险。一大批自由程序员对KDE项目的决定深为不满,它们认为利用非自由软件开发违背了GPL的精神。于是这些GNU的狂热信徒兵分两路:其中一部分人去制作Harmonny,试图重写出一套兼容Qt的替代品,这个项目虽然技术上相对简单,但却没有获得KDE项目的支持;另一路人马则决定重新开发一套名为“GNOME(GNU Network Object Environment)”的图形环境来替代KDE。
GNOME选择完全遵循GPL的GTK图形界面库为基础,因此我们也一般将GNOME和KDE两大阵营称为GNOME/GTK和 KDE/Qt。与Qt基于C++语言不同,GTK采用较传统的C语言 ,虽然C语言不支持面向对象设计,看起来比较落后,但当时熟悉C语言的开发者远远多于熟悉C++的开发者。加之GNOME/GTK完全遵循GPL版权公约,吸引了更多的自由程序员参与。