GUI és a Linux

Az XWindow rendszer megalkotásánál más szemléletet alkalmaztak, mert nem egy asztali OS megjelenítő rendszereként lett megtervezve, hanem különféle nagygépes rendszerek hálózati GUIjának. Az X egy hálózati protokol, mely arra lett optimalizálva, hogy minél kisebb sávszélesség mellett képes legyen képes a megjelenítő eszköz helyétől és típusától független megjelenteni a grafikus tartalmat és a bemeneti eszközök helyétől és típusától függetlenül legyen képes az eseményeket szabványos formában a felhasználói alkalmazásnak átadni. Mint ilyen az X nem foglalkozik a megjelenítendő tartalommal csakis a kommunikációval.
Az Xwindow gyakorlati implementációja egy szerver kliens felállás, ahol a szerver fut a megjelenítő eszközön és ehhez kliensként csatlakoznak az alkalmazások. Az X nem köti ki a szerver implementációjának a formáját egyetlen kritérium, hogy az megfeleljen a szabványnak. Csak példaként pár X szerver implementáció: X.org, Xfree86, Cygwin/X, Xming, xgl, Wayland Display Server, MicroXwin
A fent felsorolt implementációk, mind-mind különböznek abban, hogy milyen operációs rendszeren futnak és miképp érik el az adott rendszer videóeszközeit. Amiben közösek, hogy mindegyik képes fogadni egy szabványos Xkliens által kezdeményezett kapcsolatot és megjeleníteni az általa küldött grafikus tartalmat.
A tipikus X kapcsolat felépítése:
Videó eszköz <=> X szerver <=> Felhasználói program (X kliens)

Itt kell még egy kis kitérőt tennünk. Gyakran hangoztatott érv, hogy Linux alatt szarok a grafikus driverek, lassú/bugos a 3D gyorsítás. Ezek hátterében az Linux kernelfejlesztőinek a videoeszközöktől történelmi merev elzárkózása és a videokártya gyártók titkolódzása állt. A linux kernelnél hosszú ideig nem volt egységes videoeszköz kezelés. Az ehhez legközelebb álló framebuffer kernelmodul kifejlesztése mögött is csak nem-PC architektúrák fejlesztőinek a nyomása állt. (Számos rendszeren hiányzik a PCk karakteres videomódja. Az ilyen rendszereknél grafikusan kell legenerálni a konzol karaktereit.)
Amikor felmerült az X Linuxra történő implementálásának a kérdése, akkor az X szerver fejlesztőire várt a feladat, hogy ezt megoldják. Tehát maradt a driver írás. Ezek a driverek nem a kernelspaceben hanem affelett a userspaceben futnak, emiatt lassabb és nehézkesebb a futásuk.
A 3D kérdése még ennél is összetetteb. Az X alapban egy 2D GUI protokol, csakis 2D primitívek rajzolását/kezelését támogatja.
Az xgl fejlesztői megpróbálták kiegészíteni ezt úgy, hogy egyrészt ezeket a műveleteket is az OpenGL-en keresztül végezzék, másrészt bekerüljenek olyan implementációk amik kihasználják a 3D lehetőségit. Egyetlen gond ezzel csak az volt, hogy drivert írni senki nem akart. Emiatt a xglx igényel egy klasszikus X szervert amin megnyit egy OpenGL ablakot és azon garázdálkodnak az alkalmazások.
Tehát egy xgl-es felépítés:
Videó eszköz <=> X szerver <=> xglx <=> Felhasználói program (X kliens)

Az X futása még nem jelenti, hogy kezdődik a Desktop Linux éve. Legfőképp azért, mert az X csak a megjelenítést biztosítja, de az összes többit az alkalmazásokra bízza. Logikusan vagy az alkalmazásoknak maguknak kell biztosítani, hogy különféle rendezési műveleteket hajtsanak végre rajtuk (mozgatás, minimalizálás, háttérbe küldés, indítás, leállítás), vagy kell egy olyan alkalmazás ami egy minimális kontrolt biztosít a futó alkalmazások felett. Ez utóbbi az ablakkezelő. Az ablakkezelő legtöbbször beül az X szerver root ablakába (az a szép szürkerácsos izé, ami akkor látszik ha nincs ablakkezelő) és amikor létrehoznak egy ablakot akkor rajzol köré 4 másikat kontrol elemekkel, és valamilyen elv szerint pozícionálja azt. Ugyanígy figyeli az enter és leave notify eseményeket és a saját szabályai szerint változtat az ablakok elrendezésén. Nem épp egy atomfizika jellegű feladat, ezért az egyszerűbb ablakkezelők megállnak 8-10000 kódsornál.
Az egyik buktató az ablakkezelőknél, ha túl sokat akar a fejlesztő markolni. Ha minden egyes ablakműveletnél (fókuszváltás, minimalizálás, mozgatás) sok mindent kell az ablakkezelőnek végezni (ablaklista frissítés, aminált elemek állapotának lekérdezése és újrarajzolása, harántmozgó csellentyűcske generálása) akkor ez erőforrást fog igényelni, ami az egész műveletet lelassítja.
A másik buktató, hogy mivel az ablakkezelő is egy alkalmazás az egész GUI érzetet befolyásolja, hogyan, miképp és miben lett az ablakkezelő megírva. (Vesd össze az ION3 válaszidejét mondjuk egy GTK-s ablakkezelővel.)
Általánosan elmondható, hogy minnél csicsásabb és minnél többmindent csinál az ablakkezelő annál lassabb.
Egy pillanatra ki kell térni a kompozitáló ablakkezelőkre. Ezek úgy próbálnak gyorsítani GUI válaszidején, hogy a grafikát érintő számításigéynes részeket átadják grafikus processzornak ezáltal tehermentesítve a processzort.
Van már ablakkezelőnk is, így a jelenlegi felállás nagyjából így néz ki:
Videó eszköz <=> X szerver <=> Felhasználói program (X kliens)
|=> Ablakkezelő=^

Nagyjából ez az a pont ahol használhatóvá válik a rendszer. Vannak grafikus alkalmazásaink, tudjuk pöcögtetni az ablakokat.

Csakhogy, és itt jön a csakhogy. Csakhogy a userek azt szeretnék ha nekik lenne startmenü, toolbar, gadget, widget, óra lehetőleg lánccal. A programozók meg az szeretnék, hogy nehogy már az utolsó gördítősávig és ikonig nekik kelljen már mindezt lekódolni.
Az előbbi hatására születtek meg az asztalkörnyezetek, az utóbbira pedig a GUI toolkitek.

Egy grafikus alkalmazás méretét és sebességét erősen befolyásolja, hogy a megjelenítését végző függvények milyenek és miképp vannak megírva. Ökölszabályként elmondható, hogy minél kevésbé optimalizált a kód és minél több járulékos funkció van beépítve, annál nagyobb és lassabb kódot eredményez. Egy toolkit használata esetén a programozó nem tudja kikerülni ezt, mert sokszor nincs beleszólása magának a toolkit fejlesztésébe. Sokszor maga a toolkit tartalmaz komoly elvi hibákat. Példa rá, a GTK+ filekezelőjének az alapértelmezett előnézet generálása, ami nagyszámú filet tartalmazó könyvtár megnyitásakor komolyan megvárakoztathatja a felhasználót.

Mivel az asztalkörnyezetek erősen támaszkodnak egy-egy toolkitre, emiatt értelemszerűen megjelennek annak a hibái is. Ahogy az Enlightenment hozta az imlib bugjait, a Gnome hozza a GTK hibáit, ugyanúgy ahogy a KDE a QT-ét.
Minderre még rá is tesznek egy-egy lapáttal, a meta parserek, különféle adatbázis kezelők és IPCk értelmetlen erőltetésével. Ezek featureok hasznosak komolyabb alkalmazások esetében, de egyrészt instabillá teszik a rendszert, másrészt lelassítják az egyszerűbb alkalmazások és az egész rendszer működését.
A dolog akkor tud igazán kicsúcsosodni, amikor az ablakkezelő és a asztalkörnyezet is azonos toolkittel készül, ne adj isten a kettőt megpróbálják okosban összekeresztezni.

Egy tipikus asztalkörnyezetben futó alkalmazás:
Videó eszköz <=> X szerver <=> Asztalkörnyezet<=> Felhasználói alkalmazás
|=> Ablakkezelő=^

Amikor egy Linuxos GUI alkalmazás teljesítményét nézi az ember, figyelembe kell venni, hogy milyen asztalkörnyezetben, milyen toolkittel fut. Sok KDEs alkalmazás meglepően gyorsabb ha önmagukban és nem KDEs környezetben vannak futtatva.
Minél hosszabb a lánc, minél több lépcsőn át kerül az adat az ember orra elé a képernyőre, minél több felesleges dolgot csinál mindeközben a gép, annál lassabbak lesznek az alkalmazások.

Update: Sajna a drupal szétcsapta az ascii magyarázatot, az ablakkezelő az Xszervernél ágazik le és az alkalmazással fut párhuzamosan.