Často jsem na různých přednáškách říkal, že Firefox na Waylandu vypadá úplně stejně jako na X11, běží stejně rychle, jen v něm nefunguje flash, takže je opravdu na co se těšit. Myslím si, že to v zásadě to platí i dnes.
Co je Wayland
V první řadě co je to Wayland. Z pohledu aplikace dostanete kus paměti (wayland buffer), do kterého si můžete kreslit, co chcete a až jste hotovi, pošlete to kompozitoru na vykreslení a dál se o nic nestaráte. Oproti X11 triviální záležitost, pamětníci si vzpomenou na VESA BIOS Extensions které fungovalo podobně. Je tu drobný rozdíl, wayland buffer obvykle není přímo na grafické kartě (ale může být) nýbrž se používá sdílená paměť (shm).
Proč se vlastně stěhovat z X11 na Wayland, když X11 je za ty roky dobře odladěné a relativně funkční? Každý, kdo dělal něco složitějšího na X11, musel k tomuto systému nutně pojmout určitý druh antipatie, až nenávisti. Jen ve Firefoxu existují asi čtyři různé metody pro vykreslování 2D v X11 (Xrandr, MIT-SHM, XPutImage, Xlib Cairo surfaces) a každá má nějaké záludné chyby/mouchy na různých konfiguracích. Protože aktuální funkčnost závisí na hardwarových ovladačích, aplikace nemá šanci zjistit, co funguje/nefunguje, popřípadě co je jen nějakým způsobem emulované. Bez OpenGL (také vždy ne zcela funkčního) na nějakou akceleraci tedy rovnou zapomeňte.
Další zkušenosti praví, že lidé kolem Linux mají ambice dostat Linux na kdejaké zařízení od mikrovlnné trouby, přes telefony, až po zábavné systémy v autech a letadlech. Implementovat a provozovat na takových konfiguracích X11 je noční můra srovnatelná s nasazením Windows Mobile. Oproti tomu vykreslit kus paměti z wayland bufferu zvládne každý jednočip.
Proč to Firefoxu tak dlouho trvalo?
Vykreslit něco na obrazovku je jedna věc, ale vykreslit a provozovat funkční aplikaci, je něco jiného – uživatelé KDE/Wayland by o tom mohli vyprávět. Architekti Waylandu totiž ve svém nadšení ze specifikace vyházeli spoustu (podle nich) balastu a radovali se z krásné a čisté funkcionality. Tuto radost jim tehdy nemohlo nic zkazit, hlavně proto, že kolem roku 2010 žádná reálná aplikace Wayland nepoužívala.
Relativní slabina Waylandu je také klíčová role kompozitoru. Wayland je totiž jen protokol pro komunikaci mezi aplikací a kompozitorem, který onen zmíněný wayland buffer musí dostat na grafický hardware. Existují různé metody a konkrétně Mutter (kompozitor Gnome) tento buffer nahrává do GL textury a celý desktop je potom vykreslený podobně jako např. 3D hry.
Každý kompozitor má ale svoje libůstky a co funguje v Mutteru nemusí fungovat na KDE (Kwim) nebo Sway a naopak. Existuje sice referenční kompozitor Weston, ale ten je také zabugovaný, takže reálně se za referenční kompozitor považuje Mutter, na kterém je také Firefox odladěný.
Už jen samotné vykreslování je lehce dobrodružné. Pokud nepoužijete OpenGL, potažmo Mesa, je třeba zajistit wayland buffer a odeslat jej do kompozitoru. Kompozitor si buffer převezme, převede na obrazovku (nějak) a pošle aplikaci zpět zprávu, že buffer je volný pro další zápis. Pokud máte štěstí a kompozitor je dostatečně rychlý (popř. vaše aplikace pomalá), můžete pro další vykreslení použít ten samý buffer. Většinou ale štěstí nemáte a pokud aplikace potřebuje vykreslovat a žádný wayland buffer není k dispozici, přichází komplikace.
První možnost je data aplikace prostě zahodit (frame drop). Dá se použít u fullscreen přehrávání videa, jinak budete alespoň ve Firefoxu odměněni různými dírami a fleky ve výsledném obrazu, popř. blikáním ovládacích prvků. Bohužel rychlost kompozitoru není možné nějak zjistit, takže i když se snímky ve výsledku zahodí, stejně se musí dekódovat.
Další řešení je prostě obrazová data mezi snímky kompozitoru ukládat bokem a při obdržení frame callback vše složit do jednoho wayland bufferu a odeslat. Tuto metodu používá Gtk a v základu také Firefox, nicméně dá se přemluviti k přímému rendering pomocí widget.wayland_cache_mode. Na druhou stranu Mutter ve Fedoře 31 je už velmi rychlý a většinou stíhá uvolnit wayland buffer před dalším snímkem.
Další zákeřná věc je systém oken. Wayland vyžaduje naprosto striktní hierarchii popup oken, každý potomek (child) musí mít vždy přesně jednoho předka (parent) a nelze mít dvě okna připojená ke stejnému nadřazenému oknu. Ovsem Firefox toto zhusta používá, např. všechna okna menu se hierarchicky vykreslují na stejné úrovni a jejich rodičem je hlavní okno aplikace. Pro Wayland jsme museli udělat složitý systém, kdy se hierarchie oken zjišťuje a nastavuje dynamicky a to i pro kontextové menu, bookmarky a podobně.
S okny na Waylandu souvisí i nemožnost jednotlivá okna pozicovat. Aplikace nemá šanci zjistit své aktuální umístění na ploše (aplikace dostane náhodné hodnoty, pokaždé jiné). Pozicovat lze pouze okna potomků, a to pouze relativně vzhledem k rodičovskému oknu, které vám ovšem může částečně nebo úplně vypadnout z obrazovky. Dále aplikace nemůže své okno umístit nad ostatní aplikace (funkce always-on-top), což je problém hlavně pro přehrávače videa.
Poslední radostí je fungování schránky a drag-and-drop. V původní specifikaci Waylandu chybí „primary selection“, čili schránka přes prostřední tlačítko. Až tlak uživatelů si vyžádal její implementaci v podobě rozšíření. V otázce schránky má ovšem máslo na hlavě hlavně Firefox, jelikož podporuje pouze synchronní režim, zatímco Gtk/Wayland je asynchronní. Bylo tedy třeba implementovat synchronní režim i pro Firefox a protože obsluha schránky a drag-and-drop jsou ve Waylandu spojené na úrovni protokolu, bylo třeba toto implementovat od základu a nedala se použít Gtk nadstavba.
Má tedy Wayland vůbec nějaké výhody?
Aktuální výhody Waylandu se jen těžko objektivně hodnotí. Vím pouze o jedné reálně používané, a to možnost nastavit HiDPI režim nezávisle na hardware. Plynulejší nebo hladší vykreslování oproti X11 jsem alespoň na mém notebooku (Lenovo T460p/i7/Intel HD Graphics 530) nezaznamenal a o žádné populární Wayland aplikaci běžící v kontejneru/sandboxu, co by těžila z lepšího zabezpečení Wayland protokolu, také zatím nevím.
Pro autory software má ale Wayland přece jen jednu zásadní výhodu. Nasazují jej pouze nejnovější distribuce a například Mutter vyžaduje bezproblémovou funkci OpenGL. Firefox tedy může na Waylandu bez obav povolit hardwarovou akceleraci, i když je na X11 jinak vypnutá – pokud se tedy zrovna neobjeví něco jako bug 1210727, se kterým jsem bez hmatatelného výsledku strávil pěkných čtrnáct dní.
Směr vývoje je zkrátka daný a pokud se časem povede Wayland dodělat a opravit tak, aby běžný uživatel nepoznal rozdíl od X11, nebude třeba Wayland zatracovat.
ČLÁNKY DO MAILU