Linux miniGUI移植分析

框架介绍

常用GUI程序对比

https://www.cnblogs.com/zyly/p/17378659.html

MiniGUI分为底层的GAL（图形抽象层）和IAL（输入抽象层），向上为基于标准POSIX接口中pthread库的Mini-Thread架构和基于Server/Client的Mini-Lite架构。其中Mini-Thread受限于Thread模式，对于整个系统的可靠性影响——进程中某个Thread的意外错误可能导致整个进程的崩溃，该架构应用于系统功能较为单一的场合。Mini-Lite应用于多进程的应用场合，采用多进程运行方式设计的Server/Client架构能够较好地解决各个进程之间的窗口管理、Z序剪切等问题。MiniGUI-Lite上的每个程序是单独的进程，每个进程也可以建立多个窗口。
MiniGUI的GAL层技术是基于SVGA Lib、LibGDI库、FrameBuffer的native图形引擎及哑图形引擎等，对于Trolltech公司的QVFB在X Window下也有较好的支持。IAL层则支持Linux标准控制台下的GPM鼠标服务、触摸屏及标准键盘等。

GAL和IAL抽象层的概念类似Linux内核虚拟文件系统的概念。它定义了一组不依赖于任何特殊硬件的抽象接口，所有顶层的图形操作和输入处理都建立在抽象接口之上。而用于实现这一抽象接口的底层代码称为图形引擎或输入引擎，类似操作系统中的驱动程序。这实际是一种面向对象的程序结构，利于GAL和IAL，MiniGUI可以在许多已有的图形函数库上运行，比如SVGAlib和LibGGI。并且可以非常方便地将MiniGUI移植到其他POSIX系统上，只需要根据我们的抽象层接口实现新的图形引擎即可。比如，在基于Linux的系统上，我们可以在Linux FrameBuffer驱动程序的基础上建立通用的MiniGUI图形引擎。实际上，包含在MiniGUI 1.0.00版本中的私有图形引擎（Native Engine）就是建立在FrameBuffer之上的图形引擎。一般而言，基于Linux的嵌入式系统均会提供FrameBuffer支持，这样私有图形引擎可以运行在一般的PC上，也可以运行在特定的嵌入式系统上。MiniGUI 体系结构之四——图形抽象层和输入抽象层及 Native Engine 的实现（一）_minigui lineto-CSDN博客

如上所示：从下到上，MiniGUI包括以下模块：

图形抽象层（GAL）：GAL隐藏不同操作系统或设备之间的差异，为MiniGUI上层提供统一的图形界面。在GAL中，它包含支持Linux帧缓冲区，eCos LCD等设备的软件组件。这些软件组件调用底层的设备接口，以实现特定的GAL操作，如打开设备、设置分辨率和视频模式、关闭设备等。我们将这些组件成为“GAL”引擎。其概念类似于操作系统中的设备驱动程序。
输入抽象层（IAL）：与GAL类似，IAL隐藏了键盘、小键盘、鼠标和触摸屏等各种输入设备之间的差异，为上层提供了通用接口。为了支持不同的键盘、触摸屏或鼠标界面，您可以编写自己的IAL引擎。MiniGUI通过IAL引擎支持Linux控制台、触摸屏、遥控器、键盘和其他输入设备。
图形设备接口（GDI）：该模块基于GAL，为上层应用程序提供与图形相关的接口，如绘制曲线、渲染文档、填充矩形等。GDI包含其他独立的子模块，如字体和字符集支持、图像支持等。
消息模块：该模块基于IAL，实现了MiniGUI的消息传递机制，为上层提供了一个全面的管理界面。众所周知，几乎所有的GUI系统都是事件驱动的，因此它自己的操作和GUI应用程序的操作都依赖于消息传递模块。
窗口模块和控件/小部件。基于GDI和消息传递模块，MiniGUI实现了窗口化模块。该模块提供基本界面，用于为上层应用程序创建主窗口和控件（小部件），并负责维护控件类。控制类是获得程序代码可重用性的重要概念。通过使用一个控件类，我们可以创建属于某类控件类的多个控件实例，一遍这些实例可以使用控件类的相同代码。通过这种方式，我们可以实现类似于C++的类/实例概念，这可以尽可能地重用现有代码，并提高软件的可维护性。控件模块实现了许多常用控件，如静态框、按钮、编辑框、列表框、组合框等。
外观和感觉。该模块是MiniGUI V3.0中引入的。它可用于自定义主窗口和控件的外观。在以前的版本中，定制主窗口和控件的能力并不是一个独立的模块，但我们仍然可以通过配置选项使MiniGUI的主窗口和控件具有三种外观样式：PC3D（类似于PC的样式）、FLAT和FASHION。在MiniGUI3.0中，应用程序可以完全自定义主窗口和控件的外观。当您创建主窗口或控件时，通过指定外观渲染器（LFRDR）的不通名称，您将获得主窗口或控制的不同外观。

MiniGUI提供了基本的窗口和图形界面以及许多标准控件（工具包）。除了MiniGUI之外，FMSoft还为开发人员提供了一些组件，让开发者更容易开发应用程序。

mGUtils: 一个包含 ColorSelectionDialogBox, FileOpenDialogBox 等各种实用程序的 MiniGUI 组件。
mGPlus: 一个 MiniGUI 组件，它支持高级图形功能，如路径、渐变、抗锯齿拉伸和颜色组合。
mGEff: mGEff 为 MiniGUI 应用程序提供了一个动画框架。它还提供一些流行的 UI/UE 特效。
mGNCS: 该组件为 MiniGUI 应用程序提供了一个新的控件集。
mGNCS4Touch: 该组件为带有触摸屏的设备提供了一些新控件，这些控件符合 mGNCS 的新控件 API 规范。

在4.0.4这个版本中，我们主要对 MiniGUI 的 DRM 引擎进行了增强，将 MiniGUI 与 Mesa 和 Cairo 进行集成，例如：实现了 MiniGUI 平台的 EGL。

修改:
- 将旧的 dri NEWGAL 引擎的名称更改为 drm.
- 将 DRM 引擎的配置选项更改为 --enable-videodrm。
- 将 DRM 引擎的宏更改为 _MGGAL_DRM。
- 将 DRM 引擎的运行时配置部分更改为 drm。
增强:
- 用于 GPU 集成的新 API，如 IsMemDC、IsScreenDC、IsWindowDC、GetVideoHandle 和 drmGetDeviceFD。
- 为 DRM 引擎添加新操作：create_buffer_from_prime_fd.
- 使用 dlopen 加载外部 DRM 驱动程序。
- 为 DRM 引擎添加新的运行时配置密钥 drm.exdriver 来定义外部 DRM 驱动程序。

运行模式

Linux minigui中有两种运行模式：fbcon和qvfb
fbcon：Frame Buffer Console
qvfb: Qt Virtual Frame Buffer
看名字就知道fbcon在控制台下运行，这种模式下你不能开linux的X图形界面，使用不方便。qvfb则是带帧缓冲的虚拟控制台，Linux minigui程序在qvfb中运行就像我们在图形界面下的Terminal中运行命令一样。两种模式我都试过了，详细配置如下：

为了适合不同的操作系统环境，可将 MiniGUI 配置成三种不同的运行模式：

MiniGUI-Threads

运行在 MiniGUI-Threads 上的程序可以在不同的线程中建立多个窗口，但所有的窗口在一个进程或者地址空间中运行。这种运行模式主要用来支持大多数传统意义上的嵌入式操作系统，比如 VxWorks 、ThreadX、Nucleus、OSE、pSOS、uC/OS-II、eCos等等。当然，在 Linux 和 uClinux 上，MiniGUI 也能以 MiniGUI-Threads 的模式运行。

MiniGUI-Processes

和 MiniGUI-Threads相反，MiniGUI-Processes 上的每个程序是单独的进程，每个进程也可以建立多个窗口，并且实现了多进程窗口系统。MiniGUI-Processes 适合于具有完整 UNIX 特性的嵌入式操作系统，比如嵌入式 Linux。该运行模式在 MiniGUI V2.0 中提供。

MiniGUI-Standalone

这种运行模式下，MiniGUI 可以以独立任务的方式运行，既不需要多线程也不需要多进程的支持，这种运行模式适合功能单一的应用场合。比如在一些使用 uClinux 的嵌入式产品中，因为各种原因而缺少线程支持，这时，就可以使用 MiniGUI-Standalone 来开发应用软件。

一般而言，MiniGUI-Standalone 模式的适应面最广，可以支持几乎所有的操作系统（目前只用来提供对 Linux/uClinux 操作系统的支持）；MiniGUI-Threads 模式的适用面次之，可运行在支持多任务的实时嵌入式操作系统，或者具备完整 UNIX 特性的普通操作系统；MiniGUI-Processes 模式的适用面较小，它仅适合于具备完整 UNIX 特性的嵌入式操作系统，比如 Linux。但不论采用哪种运行模式，MiniGUI 为上层应用软件提供了最大程度上的一致性；只有少数几个涉及初始化的接口在不同运行模式上有所不同。

hello word程序

MiniGUI——第一个程序helloworld_color_lightwhite-CSDN博客

窗口过程和句柄

窗口过程是什么

窗口过程是一个特定类型的函数，用来接收和处理所有发送到该窗口的消息。每个控件类都有一个窗口过程，属于同一控件类的所有控件共用一个窗口过程来处理消息。窗口过程函数是MiniGUI程序的主体部分，应用程序实际所做的工作大部分都发生在窗口过程函数中，因为MiniGUI程序的主要任务就是接收和处理窗口收到的各种消息。窗口过程函数由MiniGUI调用，是一个回调函数。

窗口过程函数一般定义的形式：

static int HelloWinPro(HWND hWnd, int message, WPARAM wParam, LPARAM lParam)

hWnd:接收消息的窗口的句柄，与CreateMainWindow函数的返回值相同，该值表示了接收该消息的特定窗口。

message:与MSG结构中的message域相同，是一个表示窗口所收到消息的整数值。

wParam和IParam：都是32位的消息参数。

句柄是什么？

句柄（Handle）是一个用来标识对象或项目的标识符，可以用来描述窗体、文件等。在MiniGUI中，使用句柄访问窗口、控件、菜单、图标等。

eg:窗口句柄：用来标识窗口的唯一值。每个窗口都对应一个句柄，所有的句柄都不会重复，根据句柄可以获取对应窗口的相关信息。

代码部分

minigui 4.0 源代码分析（六） - 简书

helloworld代码部分

#include <stdio.h>
#include <minigui/common.h>   //包括MiniGUI常用的宏以及数据类型的定义
#include <minigui/minigui.h>  //包含全局接口函数和通用接口函数以及某些杂项函数的定义
#include <minigui/gdi.h>      //包含MiniGUI绘图函数的接口定义
#include <minigui/window.h>    //包含窗口有关的宏、数据类型、数据结构定义以及函数接口声明
static int HelloWinProc(HWND hWnd, int message, WPARAM wParam, LPARAM lParam)//窗口过程函数
{HDC hdc;switch (message) {case MSG_PAINT:                //该消息在需要进行窗口重绘时发送到窗口过程，处理完该消息后    直接返回hdc = BeginPaint (hWnd);       //获取设备上下文句柄//TextOut (hdc, 100, 100, "Hello world!");//文本的输出SetPenColor(hdc, PIXEL_red);Rectangle (hdc, 100, 100, 200, 200);EndPaint (hWnd, hdc);           //释放设备上下文句柄return 0;case MSG_CLOSE:                //点击关闭按钮时，应用程序在响应消息时会调用销毁窗口DestroyMainWindow (hWnd);        PostQuitMessage (hWnd);       return 0;}
return DefaultMainWinProc(hWnd, message, wParam, lParam);
}
int MiniGUIMain (int argc, const char* argv[])
{MSG Msg;HWND hMainWnd;MAINWINCREATE CreateInfo;#ifdef _LITE_VERSIONSetDesktopRect(0, 0, 800, 600);#endifCreateInfo.dwStyle = WS_VISIBLE | WS_BORDER | WS_CAPTION;CreateInfo.dwExStyle = WS_EX_NONE;CreateInfo.spCaption = "HelloWorld";CreateInfo.hMenu = 0;CreateInfo.hCursor = GetSystemCursor(0);CreateInfo.hIcon = 0;CreateInfo.MainWindowProc = HelloWinProc;CreateInfo.lx = 0;CreateInfo.ty = 0;CreateInfo.rx = 320;CreateInfo.by = 240;CreateInfo.iBkColor = COLOR_lightwhite;CreateInfo.dwAddData = 0;CreateInfo.hHosting = HWND_DESKTOP;hMainWnd = CreateMainWindow (&CreateInfo);if (hMainWnd == HWND_INVALID)return -1;ShowWindow(hMainWnd, SW_SHOWNORMAL);while (GetMessage(&Msg, hMainWnd)) {TranslateMessage(&Msg);DispatchMessage(&Msg);}MainWindowThreadCleanup (hMainWnd);return 0;
}
#ifndef _LITE_VERSION
#include <minigui/dti.c>

部分代码解释

PostQuitMessage (hWnd);

该消息在消息队列中设置一个QS_QUIT标志。GetMessage在从指定消息队列中获取消息时，会检查该标准，如果有QS_QUIT标志，GetMessage消息将返回FALSE，从而可以利用该返回值终止消息循环。

SetDesktopRect(0, 0, 800, 600);

在MiniGUI-Lite版本中，每个MiniGUI客户端程序在调用其他MiniGUI函数之前必须要调用该函数设置程序的桌面显示矩形区域。

CreateInfo.dwStyle = WS_VISIBLE | WS_BORDER | WS_CAPTION;

CreateInfo.dwStyle:窗口的风格。

WS_VISIBLE：创建一个初始状态为可见的窗口

WS_BORDER：创建一个单边框的窗口

WS_CAPTION：标题栏

CreateInfo.dwExStyle = WS_EX_NONE;

CreateInfo.dwExStyle——窗口的附加风格。

WS_EX_NONE——表示无附加窗口风格

CreateInfo.spCaption = "HelloWorld";

CreateInfo.spCaption ——窗口的标题。

CreateInfo.hMenu = 0;

CreateInfo.hMenu——附加在窗口上的菜单句柄，设置窗口的主菜单

CreateInfo.hMenu = 0;表示该窗口无主菜单

CreateInfo.hCursor = GetSystemCursor(0);

CreateInfo.hCursor—— 在窗口中所使用的鼠标光标句柄

GetSystemCursor(0);——设置主窗口的光标为系统缺省光标。(即系统默认的光标)

CreateInfo.hIcon = 0;

CreateInfo.hIcon ——程序的图标

CreateInfo.hIcon = 0;表示该窗口没有图标

CreateInfo.MainWindowProc = HelloWinProc;

CreateInfo.MainWindowProc= HelloWinProc ——设置主窗口的过程函数为HelloWinProc,发往该窗口的消息由该函数处理

    CreateInfo.lx = 0;CreateInfo.ty = 0;CreateInfo.rx = 320;CreateInfo.by = 240;

设置窗口在屏幕的位置，该窗口左上角位于(0,0),右下角位于(320,240).

CreateInfo.lx——窗口左上角相对屏幕的绝对横坐标
CreateInfo.ty ——窗口左上角相对屏幕的绝对纵坐标
CreateInfo.rx ——窗口右下角相对屏幕的绝对横坐标
CreateInfo.by ——窗口右下角相对屏幕的绝对纵坐标

CreateInfo.iBkColor = COLOR_lightwhite;

CreateInfo.iBkColor——设置窗口的背景颜色

CreateInfo.iBkColor = COLOR_lightwhite;表示设置主窗口的颜色为白色

CreateInfo.dwAddData = 0;

CreateInfo.dwAddData ——窗口的附加数据

CreateInfo.dwAddData = 0; 表示窗口无附加数据

进入消息循环

当ShowWindow函数被调用时，主窗口将显示在屏幕上。和其他 GUI 一样，是时候进入消息循环了。MiniGUI 为每个 MiniGUI 程序维护一个消息队列。事件发生后，MiniGUI 将事件转化为消息，并将消息放入目标窗口的消息队列中。那么应用程序的任务就是执行下面的消息循环代码，不断地从消息队列中获取消息并进行处理。

    while (GetMessage (&Msg, hMainWnd)) {TranslateMessage (&Msg);DispatchMessage (&Msg); }

Msg变量类型为 MSG 结构体，定义 minigui/window.h如下：

/*** 消息结构。
* \sa GetMessage, PostMessage, msgs */
typedef struct _MSG
{/** 接收此消息的窗口句柄。*/HWND hwnd;    UINT  message;         /** 消息标识符 */WPARAM wParam;         /** 消息的第一个参数（具有指针精度的无符号整数）。 */LPARAM lParam;         /** 消息的第二个参数（具有指针精度的无符号整数） */DWORD time;            /**时间*/#ifdef _MGRM_THREADSvoid*  pAdd;          /** 附加数据*/
#endif
} MSG;
typedef MSG* PMSG;

GetMessage 函数从应用程序的消息队列中获取一条消息。

GetMessage (&Msg, hMainWnd);

此函数的第二个参数是主窗口的句柄，第一个参数是指向 MSG 结构的指针。GetMessage函数用从消息队列中得到的消息填充 MSG 结构的字段，其中包括：

hwnd: 消息发送到的窗口句柄。该值是相同hMainWnd的helloworld.c程序。
message: 消息标识符。这是用于标识消息的整数。每条消息都有一个对应的预定义标识符，这些标识符定义在minigui/window.h并带有MSG_ 前缀。

wParam：第一个消息参数，不同的消息含义和取值不同。
lParam: 第二个消息参数，其含义和取值取决于消息。
time：消息放入消息队列的时间（tick count）。
只要从消息队列中得到的消息不是MSG_QUIT， GetMessage则返回一个非0值，消息循环将继续。MSG_QUIT message 消息使GetMessage返回为零，并导致消息循环终止。

TranslateMessage (&Msg);

TranslateMessage函数将击键消息转换为MSG_CHAR 消息，然后将消息发送给窗口过程函数。

DispatchMessage (&Msg);

DispatchMessage函数最终将消息发送到目标窗口的窗口过程，并让它处理消息。也就是说该函数实际上分发的是窗口过程函数的回应消息。

在这个例子中，窗口过程是HelloWinProc。也就是说，MiniGUI 在函数中调用主窗口的窗口过程函数（回调函数），DispatchMessage来处理发送到这个主窗口的消息。处理完消息后，应用程序的窗口过程函数返回DispatchMessage函数中，而DispatchMessage function最终返回应用程序代码，应用程序通过调用下一个GetMessage 函数开始新的消息循环。

窗口过程函数

窗口过程函数是 MiniGUI 程序的主体。一个应用程序的大部分工作实际上发生在窗口过程函数中，因为GUI程序的主要任务是接收和处理窗口接收到的各种消息。

在helloworld.c 程序中，窗口过程是名为HelloWinProc的函数，窗口过程函数可以由程序员任意命名，CreateMainWindow函数根据MAINWINCREATE结构中指定的窗口过程创建主窗口。
窗口过程函数定义如下：

static LRESULT HelloWinProc (HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);

窗口过程函数的四个参数与 MSG 结构的前四个域相同，第一个参数hWnd是接收消息的窗口句柄，与CreateMainWindow函数的返回值相同，表示接收消息的具体窗口。第二个参数与MSG结构的message字段相同，是一个整数值，表示接收到的消息。最后两个参数都是消息参数（两个具有指针精度的整数），提供与消息相关的特殊信息。
窗口过程函数通常不是由程序直接调用，而是由MiniGUI 调用，即回调函数。

窗口过程函数不予处理的消息应该传给DefaultMainWinProc函数进行缺省处理，从DefaultMainWinProc返回的值必须由窗口过程返回。

屏幕输出

程序在响应MSG_PAINT 消息时执行屏幕输出。应用程序首先通过调用BeginPaint函数获取设备上下文句柄，并使用它来调用GDI函数来执行绘图操作。这里，程序使用TextOut文本输出函数来显示“Hello, world!” 字符串。绘制完成后，应用程序调用EndPaint函数释放设备上下文句柄。

退出程序

当用户单击窗口右上角的关闭按钮时，窗口过程函数将收到一条MSG_CLOSE消息。helloworld程序在收到MSG_CLOSE消息时调用DestroyMainWindow函数销毁主窗口，并且调用PostQuitMessage 函数将MSG_QUIT投入到到消息队列中。GetMessage 函数在接收到MSG_QUIT消息时会返回0 ，最终导致程序退出消息循环。

程序最后调用MainWindowThreadCleanup清理主窗口使用的消息队列等系统资源，并最终由MiniGUIMain finally返回。

Linux下的图形库介绍

https://www.cnblogs.com/fly-fish/archive/2012/01/10/2318284.html

在进行Linux下的图形系统编程时，我们常常会遇到以下这些概念：

Framebuffer, X11, SDL，DFB, miniGUI, OpenGL，QT, GTK，KDE, GNOME等等。

Linux 图形领域的基础设施

X Window

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接口。

SVGALib

SVGALib（Super Video Graphics Array Lib）是Linux下的底层图形库，也是Linux系统中最早出现的非X图形支持库，它支持标准的VGA（Video graphics Array）图形模式和一些其他的模式，SVGALib的缺点是程序必须以root权限登录，并且它是基于图形卡的，所以不是所有的硬件都支持它。
自从framebuffer这个孪生姐妹诞生后，许多软件由只支持SVGALib变为同时支持两者，甚至一些流行的高层函数库如QT 和GTK只支持Framebuffer，作为一个老的图形支持库，SVGALib目前的应用范围越来越小，尤其是在 Linux 内核增加了FrameBuffer驱动支持之后。

FrameBuffer

FrameBuffer是出现在Linux2.2.xx内核当中的一种驱动程序接口。这种接口将显示设备抽象为帧缓冲区。用户可以将它看成是显示内存的一个映像，将其映射到进程地址空间之后，就可以直接对现存进行读写操作，而写操作可以立即反应在屏幕上。该驱动程序的设备文件一是/dev/fb0、/dev/fb1等等。

在应用程序中，一般通过将FrameBuffer设备映射到进程地址空间的方式来使用，比如下面的程序就打开/dev/fb0设备，并通过mmap系统调用进行地址映射，随后用memset将屏幕清空。

FrameBuffer设备还提供了若干ioctl命令，通过这些命令，可以获得显示设备的一些固定信息（比如显示内存大小）、与显示模式相关的可变信息（比如分辨率、像素结构、每扫描线的字节宽度）、以及伪彩色模式侠的调色板信息等等。

FrameBuffer实际上只是一个提供显示内存和显示芯片进村器从物理内存映射到进程地址空间中的设备。所以，对于应用程序而言，如果希望在FrameBuffer之上进行图形编程，还需要完成其他许多工作。FrameBuffer就像一张画布，用什么样子的画笔，如何画画，还需要你自己动手完成。

LibGGI

LibGGI(Lib Graphics Interface)试图建立一个一般性的图形接口，而这个抽象接口连同相关的输入（鼠标、键盘、游戏杆等）抽象接口一起，可以方便地运行在X Windows，SVGALib、FrameBuffer等等之上。建立在LibGGI之上的应用程序，不需重新编译，就可以在上述这些底层图形的接口上运行。但不知何故，LibGGI的发展几乎停滞。

在Linux上，LibGGI是通过调用FrameBuffer或SVGALib来完成图形操作的，可能速度比较慢。但在某些不支持FrameBuffer或是VGA的系统上使用LibGGI仍然是一种不错的选择。

Linux 图形领域的高级函数库

Xlib及其他相关函数库

在X Window系统中进行图形编程时，可以选择直接使用Xlib。Xlib实际上是对底层X协议的封装，可通过该函数库进行一般的图形输出。如果你的X Server支持DGA（Direct Graphics Access），则可以通过DGA扩展直接访问显示设备，从而获得加速支持。对一般用户而言，由于Xlib的接口太原始而且复杂，因此一般的图形程序选择其他高级一些的图形库作为基础。比如GTK、QT 等等。这两个函数库同时还是一些高级的图形用户界面的支持函数库。由于种种原因，GTK、QT等函数库存在庞大、占用系统资源多的问题，不太适合在嵌入式系统中使用。这时，你可以选择使用 FLTK（Fast Light Tool Kit ），这是一个轻量级的图形函数库，但它的主要功能集中在用户界面上，提供了较为丰富的控件集。

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是编写跨平台游戏和多媒体应用的最佳平台，也的确得到了广泛应用。相关信息，可参阅 Simple DirectMedia Layer - Homepage。

Allegro

　Allegro是一个专门为x86平台设计的游戏图形库。最初的Allegro运行在 DOS环境下，而目前可运行在Linux FrameBuffer控制台、Linux SVGALib、X Window等系统上。Allegro提供了一些丰富的图形功能，包括矩形填充和样条曲线生成等等，而且具有较好的三维图形显示能力。由于Allegro的许多关键代码是采用汇编编写的，所以该函数库具有运行速度快、资源占用少的特点。然而，Allegro也存在如下缺点：
1）对线程的支持较差。Allegro的许多函数是非线程安全的，不能同时在两个以上的线程中使用。
2）对硬件加速能力的支持不足，在设计上没有为硬件加速提供接口。
有关 Allegro 的进一步信息，可参阅Main。

Mesa3D

Mesa3D是一个兼容OpenGL规范的开放源码函数库，是目前Linux上提供专业三维图形支持的惟一选择。Mesa3D同时也是一个跨平台的函数库，能够运行在X Window、X Window with DGA、BeOS、Linux SVGALib 等平台上。
有关 Mesa3D 的进一步信息，可参阅 http://www.mesa3d.org/。

DirectFB

DirectFB是专注于Linux FrameBuffer硬件加速的一个图形库，并试图建立一个兼容GTK的嵌入式GUI系统。它以可装载函数库的形式提供对加速 FrameBuffer驱动程序的支持。目前，该函数库正在开发之中（最新版本 0.9.97），详情可见 http://www.directfb.org/。

嵌入式Linux系统的图形用户界面

MicoroWindows/NanoX

MicroWindows（Greg Haerr's Nano-X Window System Page (previously Microwindows)）是一个开放源码的项目，目前由美国Century Software公司主持开发。该项目的开发一度非常活跃，国内也有人参与了其中的开发，并编写了GB2312等字符集的支持。但在 Qt/Embedded发布以来，该项目变得不太活跃，并长时间停留在0.89Pre7版本。可以说，以开放源码形势发展的MicroWindows项目，已基本停滞。
　　MicroWindows是一个典型的基于客户/服务器体系结构的GUI系统，基本分为三层。最底层是面向图形输出和键盘、鼠标或触摸屏的驱动程序；中间层提供底层硬件的抽象接口，并进行窗口管理；最高层分别提供兼容于X Window和 Windows CE（Win32 子集）的API。
　　该项目的主要特色在于提供了类似X的客户/服务器体系结构，并提供了相对完善的图形功能，包括一些高级的功能，比如Alpha混合，三维支持，TrueType 字体支持等。但需要注意的是，MicroWindows的图形引擎存在许多问题，可以归纳如下：
1）无任何硬件加速能力。
2）图形引擎中存在许多低效算法，同时未经任何优化。比如在直线或者圆弧绘图函数中，存在低效的逐点判断剪切的问题。
3）代码质量较差。由于该项目缺少一个强有力的核心代码维护人员，因此代码质量参差不齐，影响整体系统稳定性。这也是MicroWindows长时间停留在 0.89Pre7 版本上的原因。
　　MicroWindows 采用MPL条款发布（该条款基本类似 LGPL 条款）

OpenGUI

OpenGUI（Official OpenGUI home page）在Linux系统上存在已经很长时间了。最初的名字叫FastGL，只支持256色的线性显存模式，但目前也支持其他显示模式，并且支持多种操作系统平台，比如 MS-DOS、QNX 和Linux等等，不过目前只支持x86硬件平台。OpenGUI也分为三层。最低层是由汇编编写的快速图形引擎；中间层提供了图形绘制API，包括线条、矩形、圆弧等，并且兼容于 Borland的BGI API。第三层用C++编写，提供了完整的GUI对象集。
　　OpenGUI采用LGPL条款发布。OpenGUI比较适合于基于x86平台的实时系统，可移植性稍差，目前的发展也基本停滞。

Qt/Embedded

　Qt/Embedded是著名的Qt库开发商TrollTech（http://www.trolltech.com/）发布的面向嵌入式系统的Qt版本。因为Qt是KDE等项目使用的GUI支持库，所以有许多基于Qt 的X Window程序可以非常方便地移植到Qt/Embedded版本上。因此，自从Qt/Embedded以GPL条款形势发布以来，就有大量的嵌入式Linux开发商转到了Qt/Embedded系统上。比如韩国的Miz 公司，台湾省的某些嵌入式Linux应用开发商等等。
　　不过，在笔者看来，Qt/Embedded还有一些问题值得开发者注意：
1）目前，该系统采用两种条款发布，其中包括GPL条款。对函数库使用GPL条款，意味着其上的应用需要遵循GPL条款。当然了，如果要开发商业程序，TrollTech也允许你采用另外一个授权条款，这时，就必须向TrollTech交纳授权费用了。
2）Qt/Embedded是一个C++函数库，尽管Qt/Embedded声称可以裁剪到最少 630K，但这时的Qt/Embedded库已经基本上失去了使用价值。低的程序效率、大的资源消耗也对运行Qt/Embedded的硬件提出了更高的要求。
3）Qt/Embedded库目前主要针对手持式信息终端，因为对硬件加速支持的匮乏，很难应用到对图形速度、功能和效率要求较高的嵌入式系统当中，比如机顶盒、游戏终端等等。
4）Qt/Embedded提供的控件集风格沿用了PC风格，并不太适合许多手持设备的操作要求。
5）Qt/Embedded的结构过于复杂，很难进行底层的扩充、定制和移植，尤其是那个用来实现signal/slot机制的著名的moc文件。
　　因为上述这些原因，目前所见到的Qt/Embedded 的运行环境，几乎是清一色基于StrongARM的iPAQ。
注：目前，Qt/Embedded已经增加了对DirectFB驱动的支持，因此具有了图形加速能力，其性能也大大地得到提高。

MiniGUI

MiniGUI（Home :: MiniGUI）是由许多自由软件开发人员支持的一个自由软件项目（遵循 LGPL 条款发布），其目标是为基于Linux 的实时嵌入式系统提供一个轻量级的图形用户界面支持系统。该项目自 1998 年底开始到现在，已历经3年多的开发过程。到目前为止，已经非常成熟和稳定。目前，已经正式发布了稳定版本 1.0.9，并且开始了新版本系列的开发，即 MiniGUI Version 1.1.x，该系列的正式版也即将发布。

linux和windows下界面系统的区别

图形界面并不是linux的一部分 ,linux只是一个基于命令行的操作系统,linux和Xfree的关系就相当于当年的DOS和 WINDOWS3.0一样,windows3.0不是独立的操作系统,它只是DOS的扩充,是DOS下的应用程序级别的系统,不是独立的操作系统,同样 XFree只是linux下的一个应用程序而已.不是系统的一部分,但是X的存在可以方便用户使用电脑.WINDOWS95及以后的版本就不一样了,他们的图形界面是操作系统的一部分,图形界面在系统内核中就实现了,没有了图形界面windows就不成为windows了,但linux却不一样,没有图形界面linux还是linux,很多装linux的WEB服务器就根本不装X服务器。这也WINDOWS和linux的重要区别之一。

关于linux两大图形界面KDE和Gnome

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版权公约，吸引了更多的自由程序员参与。

X window的图形显示处理原理

X Window从逻辑上分为三层：最底层的X Server（X服务器）主要处理输入/输出信息并维护相关资源，它接受来自键盘、鼠标的操作并将它交给X Client（X客户端）作出反馈，而由X Client传来的输出信息也由它来负责输出；最外层的X Client则提供一个完整的GUI界面，负责与用户的直接交互（KDE、Gnome都是一个X Client），而衔接X Server与X Client的就是“X Protocol(X通讯协议)”、它的任务是充当这两者的沟通管道。尽管UNIX厂商采用相同的X Window，但终端的X Client并不相同。

Qt、GTK 和KDE、GNOME的关系

简单来说：为了方便开发人员编写X clients，就有了Xlib来封装X协议；Xlib还不够方便，于是就有了qt和gtk，它们提供了很多窗口控件（widgets）。
为了方便用户，就出现了gnome和kde等桌面管理系统。一般来说，linux用户看到的界面就是其中之一了。gnome用的是gtk库，kde用的是qt库。

GTK(GIMP Toolkit) 是一套跨多种平台的图形工具包，按 LGPL 许可协议发布的。虽然最初是为 GIMP 写的，但目前已发展为一个功能强大、设计灵活的一个通用图形库。特别是被 GNOME 选中使得 GTK + 广为流传，成为 Linux 下开发图形界面的应用程序的主流开发工具之一，当然 GTK + 并不要求必须在 Linux 上，事实上，目前 GTK + 已经有了成功的 windows 版本。

GIMP （GNU Image Manipulation Program，GNU图像处理程序），它是一个图像处理与合成工具。GIMP的扩展性很强，用户可以通过自己编写的插件来扩充GIMP功能。

GNU是一个操作系统，其内容软件完全以GPL方式发布。这个操作系统是GNU计划的主要目标，名称来自GNU's Not Unix!的递归缩写，因为GNU的设计类似Unix，但它不包含具著作权的Unix代码。GNU的创始人，理查德·马修·斯托曼，将GNU视为“达成社会目的技术方法”。

KDE和QT的关系

QT是一个适用于各种操作系统的应用程序框架。它可能以创建图形界面而闻名，但也有用于其他目的的库，如多媒体或网络功能。

KDE（即K桌面环境，全称K Desktop Environment）主要是一个图形桌面环境，如Gnome（GNU Network Object Model Environment)或xfce，然后，它还包含不属于桌面环境的范围广发的应用程序，例如办公套件、游戏等等。所有这些程序都使用核心KDE库，这些库用于显示窗口、授予网络/文件访问权限等。关键是，这些KDE库不是从头开始编写的，而是建立在QT库之上的，所以，简单的说，KDE就是一个依赖QT的桌面环境。