Linux 下的圖形庫介紹

在進行Linux下的圖形系統編程時，咱們經常會遇到如下這些概念：

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

1、Linux 圖形領域的基礎設施 

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

1.2 SVGALib 
SVGALib是Linux下的底層圖形庫，也是Linux系統中最先出現的非X圖形支持庫，它支持標準的VGA圖形模式和一些其餘的模式，SVGALib的缺點是程序必須以root權限登陸，而且它是基於圖形卡的，因此不是全部的硬件都支持它。
自從framebuffer這個孿生姐妹誕生後，許多軟件由只支持SVGALib變爲同時支持二者，甚至一些流行的高層函數庫如QT 和GTK只支持Framebuffer，做爲一個老的圖形支持庫，SVGALib目前的應用範圍愈來愈小，尤爲是在 Linux 內核增長了FrameBuffer驅動支持以後。

1.3 FrameBuffer 
FrameBuffer是出如今Linux 2.2.xx內核當中的一種驅動程序接口。這種接口將顯示設備抽象爲幀緩衝區。用戶能夠將它當作是顯示內存的一個映像，將其映射到進程地址空間以後，就能夠直接對顯存進行讀寫操做，而寫操做能夠當即反映在屏幕上。該驅動程序的設備文件通常是/dev/fb0、/dev/fb1 等等。
在應用程序中，通常經過將FrameBuffer設備映射到進程地址空間的方式
來使用，好比下面的程序就打開/dev/fb0設備，並經過mmap系統調用進行地址映射，隨後用memset將屏幕清空（這裏假設顯示模式是1024x766-8位色模式線性內存模式）：

FrameBuffer設備還提供了若干ioctl命令，經過這些命令，能夠得到顯示
設備的一些固定信息（好比顯示內存大小）、與顯示模式相關的可變信息（好比分辨率、象素結構、每掃描線的字節寬度），以及僞彩色模式下的調色板信息等等。
FrameBuffer 實際上只是一個提供顯示內存和顯示芯片寄存器從物理內存映
射到進程地址空間中的設備。因此，對於應用程序而言，若是但願在 FrameBuf
之上進行圖形編程，還須要完成其餘許多工做。FrameBuffer 就像一張畫布，用什麼樣子的畫筆，如何畫畫，還須要你本身動手完成。

1.4 LibGGI 
LibGGI試圖創建一個通常性的圖形接口，而這個抽象接口連同相關的輸入（鼠標、鍵盤、遊戲杆等）抽象接口一塊兒，能夠方便地運行在X Window、SVGALib、FrameBuffer等等之上。創建在LibGGI之上的應用程序，不需從新編譯，就能夠在上述這些底層圖形接口上運行。但不知何故，LibGGI的發展幾乎停滯。 

2、Linux 圖形領域的高級函數庫 

2.1 Xlib及其餘相關函數庫 
　　在X Window系統中進行圖形編程時，能夠選擇直接使用Xlib。Xlib實際上是對底層X協議的封裝，可經過該函數庫進行通常的圖形輸出。若是你的X Server支持DGA，則能夠經過DGA擴展直接訪問顯示設備，從而得到加速支持。對通常用戶而言，因爲Xlib的接口太原始並且複雜，所以通常的圖形程序選擇其餘高級一些的圖形庫做爲基礎。好比GTK、QT 等等。這兩個函數庫同時仍是一些高級的圖形用戶界面的支持函數庫。因爲種種緣由，GTK、QT等函數庫存在龐大、佔用系統資源多的問題，不太適合在嵌入式系統中使用。這時，你能夠選擇使用 FLTK，這是一個輕量級的圖形函數庫，但它的主要功能集中在用戶界面上，提供了較爲豐富的控件集。 

2.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/。 

2.3 Allegro
　　Allegro是一個專門爲x86平臺設計的遊戲圖形庫。最初的Allegro運行在 DOS環境下，而目前可運行在Linux FrameBuffer控制檯、Linux SVGALib、X Window等系統上。Allegro提供了一些豐富的圖形功能，包括矩形填充和樣條曲線生成等等，並且具備較好的三維圖形顯示能力。因爲Allegro的許多關鍵代碼是採用彙編編寫的，因此該函數庫具備運行速度快、資源佔用少的特色。然而，Allegro也存在以下缺點： 
1）對線程的支持較差。Allegro的許多函數是非線程安全的，不能同時在兩個以上的線程中使用。 
2）對硬件加速能力的支持不足，在設計上沒有爲硬件加速提供接口。 
有關 Allegro 的進一步信息，可參閱http://www.allegro.cc/。 

2.4 Mesa3D
　　Mesa3D是一個兼容OpenGL規範的開放源碼函數庫，是目前Linux上提供專業三維圖形支持的唯一選擇。Mesa3D同時也是一個跨平臺的函數庫，可以運行在X Window、X Window with DGA、BeOS、Linux SVGALib 等平臺上。 
有關 Mesa3D 的進一步信息，可參閱 http://www.mesa3d.org/。 

2.5 DirectFB
　　DirectFB是專一於Linux FrameBuffer硬件加速的一個圖形庫，並試圖創建一個兼容GTK的嵌入式GUI系統。它以可裝載函數庫的形式提供對加速 FrameBuffer驅動程序的支持。目前，該函數庫正在開發之中（最新版本 0.9.97），詳情可見 http://www.directfb.org/。

3、面向嵌入式Linux系統的圖形用戶界面 
3.1 MicoroWindows/NanoX
　　MicroWindows（http://microwindows.censoft.com/）是一個開放源碼的項目，目前由美國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 條款）。 

3.2 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平臺的實時系統，可移植性稍差，目前的發展也基本停滯。 

3.3 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驅動的支持，所以具備了圖形加速能力，其性能也大大地獲得提升。

3.4 MiniGUI
　　MiniGUI（http://www.minigui.org/）是由許多自由軟件開發人員支持的一個自由軟件項目（遵循 LGPL 條款發佈），其目標是爲基於Linux 的實時嵌入式系統提供一個輕量級的圖形用戶界面支持系統。該項目自 1998 年末開始到如今，已歷經3年多的開發過程。到目前爲止，已經很是成熟和穩定。目前，已經正式發佈了穩定版本 1.0.9，而且開始了新版本系列的開發，即 MiniGUI Version 1.1.x，該系列的正式版也即將發佈。 

　　在MiniGUI幾年的發展過程當中，有許多值得一提的技術創新點，正是因爲這些技術上的創新，才使得 MiniGUI 更加適合實時嵌入式系統；並且 MiniGUI 的靈活性很是好，能夠應用在包括手持設備、機頂盒、遊戲終端等等在內的各類高端或者低端的嵌入式系統當中。這些技術創新包括： 
1）圖形抽象層。圖形抽象層對頂層 API 基本沒有影響，但大大方便了 MiniGUI 應用程序的移植、調試等工做。目前包含三個圖形引擎，SVGALib、LibGGI 以及直接基於 Linux FrameBuffer 的 Native Engine，利用 LibGGI 時，可在 X Window 上運行 MiniGUI 應用程序，並可很是方便地進行調試。與圖形抽象層相關的還有輸入事件的抽象層。MiniGUI 如今已經被證實可以在基於 ARM、MIPS、StrongARM 以及 PowerPC 等的嵌入式系統上流暢運行。 
2）多字體和多字符集支持。這部分經過設備上下文（DC）的邏輯字體（LOGFONT）實現，無論是字體類型仍是字符集，均可以很是方便地進行擴充。應用程序在啓動時，可切換系統字符集，好比 GB、BIG5、EUCKR、UJIS。利用 DrawText 等函數時，可經過指定字體而得到其餘字符集支持。對於一個窗口來講，同時顯示不一樣語種的文字是可能的。MiniGUI 的這種字符集支持不一樣於傳統經過 UNICODE 實現的多字符集支持，這種實現更加適合於嵌入式系統。
3）兩個不一樣架構的版本。最初的 MiniGUI 運行在 PThread 庫之上，這個版本適合於功能單一的嵌入式系統，但存在系統健壯性不夠的缺點。在 0.9.98 版本中，咱們引入了 MiniGUI-Lite 版本，這個版本在提升系統健壯性的同時，經過一系列創新途徑，避免了傳統 C/S 結構的弱點，爲功能複雜的嵌入式系統提供了一個高效、穩定的 GUI 系統。 
　　在 MiniGUI 1.1.0 版本的開發中，咱們參照 SDL 和 Allegro 的圖形部分，從新設計了圖形抽象層，並加強了圖形功能，同時加強了 MiniGUI-Lite 版本的某些特性。這些特性包括： 
1）MiniGUI-Lite 支持層的概念。同一層可容納多個可以同時顯示的客戶程序，並平鋪在屏幕上顯示。 
2）新的 GAL 可以支持硬件加速能力，並可以充分使用顯示內存；新 GAL 之上的新 GDI 接口獲得進一步加強。新的 GDI 接口能夠支持 Alpha 混和、透明位塊傳輸、光柵操做、YUV覆蓋、Gamma 校訂，以及高級圖形功能（橢圓、多邊形、樣條曲線）等等。 
　　MiniGUI 新版本在圖形方面的加強和提升，將大大擴展它的應用領域，但願可以對嵌入式 Linux 上的多媒體應用、遊戲開發提供支持。 
　　縱觀嵌入式 Linux 系統上的各類圖形系統方案，咱們發現，許多圖形系統（如 Qt/Embedded 和 MicoroWindows），只注重手持設備上的需求，卻不太注重其餘應用領域的需求，而其餘許多須要圖形支持的嵌入式 Linux 系統卻須要許多獨特的、高級的圖形功能，而不只僅是圖形用戶界面。爲此，在接下來的開發中，咱們還將在以下領域繼續開發 MiniGUI： 
1）提供運行在 MiniGUI上的 JAVA 虛擬機 AWT 組件的實現。 
2）提供 MiniGUI 上的OpenGL 實現。 
3）提供類QT 控件集的C++ 封裝。 
3）提供窗口/控件風格主題支持。 
4）在 MiniGUI-Lite 當中增長對矢量字體的支持。

4、Linux/Unix系統圖形界面原理簡單介紹及GTK、QT、GNOME和KDE的關係

最近IT新聞出現較多的就是諾基亞的新版手機操做系統Symbian 3。今天看到在cnbeta上看你們爲這個系統爭論不休，其焦點也逐漸轉移到到塞班新系統的核心技術：Qt 。評論區你們脣槍舌戰，不過不少人連基本概念都沒搞明白，今天正好無事可作，稍微整理下X11,GTK,QT,GNOME，KDE的區別與聯繫。

1、在這以前你必需要了解： 

1.linux是基於Unix的

2.塞班Symbian、蘋果max os等系統的最底層也是unix

3.linux自己沒有圖形界面,linux如今的圖形界面的實現只是linux下的應用程序  

 實現的

4.Xwindow、Xfree中的X是協議,不是具體的某個軟件

5.linux圖形界面層次關係：linux自己-->X服務器<-[經過X協議交談]->窗口管

 理器(綜合桌面環境)-->X應用程序

2、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的重要區別之一。

3、關於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版權公約，吸引了更多的自由程序員參與。

4、linux/unix基於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並不相同。

5、Qt、GTK 和KDE、GNOME的關係 

簡單來講：爲了方便開發人員編寫X clients，就有了Xlib來封裝X協議；Xlib還不夠方便，因而就有了qt和gtk，它們提供了不少窗口控件（widgets）。
爲了方便用戶 ，就出現了gnome和kde等桌面管理系統。通常來講，linux用戶看到的界面就是其中之一了。gnome用的是gtk庫，kde用的是qt庫。