> Nem másztam bele nagyon a témába, de tudtommal a compositingre épít az egész. Mióta van hardveresen gyorsított compositing X.orgban? 10+ éve biztosan.
És? Szerinted ez ennyi, hogy ez is compositing, meg az is? Ilyen egyszerű és kész? Hát nem. A Wayland az "local" render, az X11 meg kliens-szerver alapú, lévén anno arra lett kitalálva, hogy a szervergépen fut az X11 szerver és a terminálokon az X11 kliensek, ennek megfelelően teljesen más a compositing flow a kettőben: X11, WL
Ezek miatt a - local / kliens-szerver felállás miatti - különbségekből egy csomó működésbeli eltérés adódik.
A Wayland, mivel local renderer, ad egy buffert és azt csinálsz vele, amit akarsz. Az X11 viszont kliens-szerver kommunikációt csinál, ami akár gépek között is mehet, ennek megfelelően a tervezésénél a kliens-szerver kommunikáció minimalizálása volt a fő szempont és ennek megfelelően neki pl. van drawing API-ja, mert nagyon nem volt mindegy, hogy a módosított terület minden egyes bitjét átküldöd egy négyzet kirakásához (sok kB), vagy csak egy sima XFillRectangle tokent, meg az argumentumokat. A Waylandban viszont ilyen nincsen, mert egyszerűen nincs rá szükség, minden rajzolás így is helyben történik meg, tehát a drawing API-val nem rövidítenéd le a kirajzolás idejét.
Vagy másik példa: az X11 képes síkokban (bitplane) kezelni a bitmap-eket, ugyanis nem volt ritka, hogy az egyik terminál csak monokróm, a másik 16, a harmadik meg 256 színű, így az egyiknek elég volt csak egy bitet átküldeni, a másiknak meg négyet, csak a harmadiknak kellett mind a nyolcat. Ez nem csak a kommunikáció csökkentése miatt volt, hanem azért is, mert a terminálok túl gyengék voltak a szerverhez képest, hogy ők kvantizáljanak. Na, Waylandon erre sincs szükség, mert neki egy local framebuffere van, ami a videókártyának megy, közvetlenül.
Mind a két rendszert úgy tervezték meg, hogy minél gyorsabb legyen, csak éppen két - egymástól negyed évszázadnyi távolságra lévő és - teljesen eltérő korban, ahol a "gyorshoz" más volt a követelmény, mert más volt a rendszer kiépítése és ennek megfelelően, ha az egyikből a másikba wrappelsz, az minden lesz, csak gyors nem. Nem véletlen, hogy az XWayland lassú és erőforrászabáló. Ez nem a Wayland hibája, hanem az emuláció eredménye.
> A másik irány (XWayland, XQuartz) sokkal bonyolultabbnak tűnik.
http://wayland.freedesktop.org/docs/html/ch05.html
X11 and Wayland are different enough that there is no "simple" way to translate between them.
Nekik mondd.
> Tudsz ilyen feature-ről?
És ha én nem tudok, akkor nincs is?
> Tudtommal a Wayland compositor egyben ablakkezelőként is funkcionál, nyilván emiatt a window managerhez is beszélnie kell, de ennek is megvannak a standard megoldásai.
10 WM 11 féleképpen működik, ugyanis az X11-hez többféleképpen is beszélhetsz.
> Szerk.: egyébként a Weston fut X felett is, tehát a kérdést rövidre zárhatjuk.
Skippelted a válaszom első felét:
Egyrészt, mert ez így egy baromi erőforrásigényes middleware lenne, ami akár a használhatatlanságig is lassíthatja a rendszert. (Keress csak rá, hogy az XWayland, vagy a wikicikkben említett XQuartz mennyire "gyorsak" és mennyi CPU-időt hagynak meg a rendszernek.)
Szóval nem. Sem az X11 over WL, sem a WL over X11 nem megoldás hosszútávon. Nyilván, ha csak "épp kell" valami, akkor hasznos, ha van, de amúgy így nem lehet normálisan dolgozni, ha a grafikus alrendszer az emuláció miatt megzabálja a gépet.