Kompozitní manažery - Compiz a Beryl nejsou jediní

12.11.2006 22:43 | Přečteno: 2750× | desktop linux |

Jak se tak dívám na ostatní blogy, kompozitní manažery se těší pozornosti. Manuály jak nainstalovat Beryl či Compiz střídají ankety popularity a praktické návody jak používat nebo naopak stížnosti, že se používat nedají vůbec.

Všichni autoři jako by zapomněli ve svých výčtech na dva starší kompozitní manažery: xcompmgr a kompmgr. Nikdy se nestali extra populární, ani se nedivím, že o nich spouta lidí ani neví o jejich existenci. Dokonce nemají vlastní webové stránky ani nepodporují skoro žádné eye-candy efekty, na druhou stranu jde o vyzrálé projekty. Ten druhý je standardní součást KDE už nějaký ten pátek, minimálně od dob KDE 3.4. a xcompmgr je ještě starší.

Nejsou sice založené na OpenGL, ale kompozitní manažery to zcela jistě jsou. Neumí zdaleka tolik efektů, ale zvládají průhlednost, stíny a lepší synchronizaci překreslování oken – pokud nejste eye-candy fanatik, potřebujete opravdu víc? Plus, delší vývoj, takže jsou stabilnější.

Jsou ještě ze “staré školy”, kdy kompozitní mamanžer nemusel být spečený dohromady se správcem oken, takže je můžete používat s lobovolným správcem oken (Metacity, KWin ...) nicméně kompmgr byl dělaný na míru KWin.

K jejich provozu stačí 2D zapnutá akcelerace, 3D akcelerace vám k ničemu nepomůže. 2D akceleraci podporuje daleko více driverů než 3D. Bohužel ne vždy je kvalita, počet skutečně akcelerovaných funkcí, dostatečný. Viz níže. Stačí si Xorg konfiguraci zkontrolovat zapnutý RenderAccel na “on”. Což je defaultní nastavení pro většinu distribucí a driverů.

Vady na kráse, aneb všichni je mají..

Nicméně, ani oni nejsou bez problémů, mají skoro ty samé defekty jako Compiz/Beryl.

• posouvání velkých stránek ve Firefoxu je pomalé (pokud jsou na stránce animace, flash nebo gif je vše mnohem horší)
• Amarok zatíží CPU na 80% - 100% (může za to animace spektrálního analyzéru)
• blbne RealPlayer (mozillí plugin), občas se vykreslí video, občas řerný čtverec s logem RP.
• v podstatě jakákoliv GUI aplikace s viditelnou animací je pomalá, zatíží CPU na 80-100% (výjimka: akcelerované video, hry..)
• některé KDE skiny mají drobné artefakty (Klearlook) některé ne (Plastic)
• problikávání černých obrysů menu při rychlém střídání menu. Někdy i při pohybu okna.

Specifické problémy

• některé efekty, speciálně průhlednost, mohou být pomalejší než u Berylu. Může za to fakt, že RenderAccel u některých driverů, jako je můj radeon, nepodporuje akceleraci u některých funkcí. Stručně řečeno, průhlednost je nepoužitelně pomalá, na rozdíl od Berylu.
• A ještě jinak řečeno, 2D akcelerace může být u některých driverů v ještě horším stavu než 3D akcelerace, takže se kompmgr může zdát ještě pomalejší než Beryl.

Rozdíly xcompmgr, kompmgr z pohledu uživatele

Funkčně žádné. Jen kompmgr má o něco lepší odezvu pod KDE, žádné překvapení, byl dělán KDE na míru. Zdrojové kódy kompmgr vychází xcompmgr, trochu podobná situace jako s Berylem a Compizem. Mimochodem, mám takový dojem, že spoluautorem kompmgr je i Luboš Luňák, občasně působící i zde na abclinuxu.

Instalace a spuštění kompmgr

Kompmgr samozřejmě najdete v Kubuntu, nic nemusíte doinstalovat. Stačí spustit. Buď z příkazové řádky, stejnojmenným příkazem, nebo v Kontrolním Centru - Window Behaviour – Translucency zaškrtnete povolit používání průhlednosti a stínů (Use translucency/shadows) a případně si pohrajete s podrobnějším nastavením.

Automatic server-side compositing

Oba kompozitory můžete spustit v tomto zvláštním režimu, stačí je spustit s parametrem -a. tento režim nemá žádné efekty a také nevyžaduje vůbec žádnou (?) HW akceleraci desktopu.

Žádné efetky, k čemu je tedy dobrý? Zbaví vás “duchů” při posouvání oken, kdy vidíte jak se vám překresluje, původně překrytá, část spodního okna nebo desktopu. Také mizí některé drobné artefakty některých KDE skinů (Plastik).

Těm duchům při posouvání oken bych rád věnoval samostatný zápisek v blogu. Alespoň zjistím, jestli jsem jediný, kdo je pozoruje a nestraší mi třeba jen v hlavě Zkusím je vyfotit, pro ty co by třebas nevěřili...

P.S.

Jak tak koukám, to jsme se ale docela rozepsal. to je pomalu materiálu na samostatný článek.

Odkazy

Kompmgr homepage (něco na ten způsob) a krapet té dokumentace:
http://docs.kde.org/stable/en/kdebase/kompmgr/index.html

Legendární zdroj informací, řada praktických rad a řešení problémů nejen pro xcompmgr:
http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency

       

Komentáře

[Thunder.m]

Ještě bych doplnil, že E17 má svůj vlastní modul pro kompozitního managera, který využívá knihovny xcompmgr, s názvem Bling. Jinak z těch problémů co jste popsal se na mě asi žádný nevztahuje, což je dost divné, používám jak xcompmgr, tak bling, ale ani jedno mi to nedělá, každopádně mi to dost zlobilo ve starším Xorg (7.0 a nižší například v tvtime) a se staršími ovladači od Nvidie, poslední BETA (97.42) chodí velmi stabilně, například 4 dny v kuse bez nějakých problémů, dokonce hraju i hry (ty jsou však malinko pomalejší).

[Thunder.m]

Ještě jsem zapoměl říct, že celé chování vnitřku oken (firefox a scrollování, resize atd..) se mi zdá uplně stejné jako při nepoužití kompozitního managera tj. subjektivně velmi svižné, pokud používám beryl, nebo compiz, tak je to všechno o dost pomalejší, to je pro mě hlavní důvod nepoužívat beryl a compiz ale jen xcompmgr (alias bling).

[Espinosa]

To máme bohužel rozdílné zkušenosti. Posun delší stránky je u mě sice pod xcompmgr o něco rychlejší než pod Berylem, to je fakt, ale přeci jen znatelně pomalejší než pod čistým KWin. Ale největší "brzdou" jsou animace na stránkách, speciálně reklamy na aktualne.cz a idnes.cz, ty dokážou vytočit CPU do nebeských výšin.

Ale to je nic proti Amaroku. Stačí animovaný obdélníček velikosti 400x40 (i menší) s obnovovací frekvencí 30fps a CPU je na 90%. To je docela drsné. Naštěstí to není taková katastrofa, playlist stejně sestavím, pustím a okno zavřu a je vše OK. Jen to ale demonstruje, že současná implementace kompozitu a animace se nemají rádi.

Také mě napadlo, v Compizu je obsah oken vlastně textura, textura na 3D objektu, na obdélníku v prostoru, takže asi dost závisí na prostupnosti sběrnice pro velké textury, tj. rychlost AGP, případně eXpressu, schopnostech karty (HW) si poradit s velkou texturou a jejími změnami (animace) a taky jak driver optimalizován na velké textury.

[Daniel Kvasnička ml.]

Neumí zdaleka tolik efektů, ale zvládají průhlednost, stíny a lepší synchronizaci překreslování oken – pokud nejste eye-candy fanatik, potřebujete opravdu víc?

No jedna z veci, proc bych takovou vec pouzival je to, co se v OS X jmenuje Exposé. A to je hodne prakticka vec.

Ty vady na krase jsou dost zasadni. Kdyz jsem cetl ten clanek na Linux.com, jehoz autor povazuje Beryl za lepsi nez OS X, rikal jsem si, ze je asi trochu moc vyjuchanej. To tvrzeni je celkem smesne...

[Thunder.m]

Podstatná vada na kráse je že MAC OS X trpí podobným problémem jako Beryl, nebo Compiz a to sice že je vykreslování vnitřku okna podstatně pomalejší, tím právě u mě xcompmgr netrpí a tak je to za nulové ústupky přidání průhlednosti, stínů a hlavně výrazně rychlejší vykreslování oken, přesun oken je krásně čistý a to se mi líbí nejvíc, eye-candy je nanic pro trvalou práci, ale když přesouvám okna a občas mi pod přesouvaným oknem chybí na pár desítek milisekund obsah to považuji za nepříjemné.

[Daniel Kvasnička ml.]

MAC OS X trpí podobným problémem jako Beryl, nebo Compiz a to sice že je vykreslování vnitřku okna podstatně pomalejší

Pomalejsi nez co nebo kdy? GUI OS X mi pripadne sviznejsi nez jakekoliv jine a problemy s videem treba pri hybani oknem QuickTime jsem nezaznamenal. Zmena velikosti okna je rychla, hybani s oknem taktez. Samozrejme trochu jine je to u nenativnich aplikaci, jako napr. jEdit nebo Eclipse -- ale za to nemuze OS X. To je specialita napr. Totemu, prestat hrat kdyz se dragne okno a taha se s nim po plose...:-/

[Thunder.m]

Ano, je to pravda, původní verze byly dost pomalé, v poslední verzi (Tiger), jsou nativní aplikace velmi svižné, já ale myslím ty nenativní, které jsou stále stejně pomalé už od začátku. Předcejen raději používám například Firefox a Thunderbird, než Safari a Mail.

[Daniel Kvasnička ml.]

No tak sedim u iMaca s 2GHz G5 a Flock (odvozenina FF) je tu celkove mnohem sviznejsi nez v GTK+. Kdyz chytnu okno za pravy dolni roh a blbnu s mysi, tak je to sice horsi nez u Safari, ale stale vysoce pouzitelne.

[Thunder.m]

No u tak rychlého MACa se to už dá očekávat, v práci máme G4 1GHz s Tigerem a mohu říct že Safari je super, ale Firefox je dost cukanej, zkoušel jsem i Camino, je to skoro to samé, ale je fakt že tam všude je FF 1.5, FF 2.0 je o poznání rychlejší, Flock jsem ještě nezkoušel.

[Daniel Kvasnička ml.]

Kdyz blbnu s oknama nativnich aplikaci v Gnome na Athlonu 1800+ s Radeonem 9550, tak je to o hodne horsi nez na tom Macu. Jak by se to zmenilo pri pouziti Berylu nebo pri pouziti procesoru se srovnatelnym vykonem, nevim...

Nicmene tohle jsou takove diskuse o nicem Vsichni vime, ze jsou veci, ktere produktivitu prace snizi ci zvysi o mnoho vic nez kravniny z oknama

[Espinosa]

No MacBooka má například kolega na stole, hraje si s tím tady intenzivně už měsíc, a nemůžu si pomoct, vše co jsem viděl na OSX umí i Beryl. Spíš mi to přijde takové celkově dotažené, jak vzhledově tak funkčně, do detailu, žádné artefakty, svižné, žádné pomalé scrolování, problémy s videem. Aby ne, pokročilé compozitní manažery jsou na linuxu poměrně novinka, začali se vyvýjet v době kdy Apple vydával ostrou verzi svého. Délku vývoje je třeba vždy brát v úvahu při porovnávání. Myslím, že Compiz/Beryl posunuli hranice desktopového linuxu v relativně krátkém čase o pořádný skok dopředu. Jinak Berylu chci věnovat vlastní zápisek, takže trochu předjímáme.

[David Watzke]

Kompmgr zas tak stabilní není. Stačí například chvíli podržet hotkey Yakuake a sbohem KDE

[Thunder.m]

A pro ty co nepoužívají KDE nějaký typ na schození, mimo kill? :)

[Luboš Luňák]

To neni problem Kompmgr, ale KWin. A jak uz jsem rekl nekolikrat, dokud mi nekdo neda dobry zpusob, jak problem zreprodukovat, tak ho proste nemuzu spravit.

[David Watzke]

Tohle není dobrý způsob? Funguje zaručeně...

[Semo]

Skusil som a nic.

epm -q yakuake kdelibs
yakuake-2.7.5
kwin-3.5.2-r2

[David Watzke]

A co když si to nastavíš nějak takhle?

[Semo]

1.) Ak na takom nastaveni normalne pracujes, tak si uchyl Pri kazdom prepnuti sa mi cely desktop tak hybe pred ocami, ze uz viem ako sa citi alkoholik v deliriu.

2.) yakuake:

semo@semo ~ $ yakuake
[doslova len par prepnuti F12 do y. a naspat]
Uh oh.. can't write data..
semo@semo ~ $
[yakuake lahlo]

semo@semo ~ $ yakuake
[20s so mdrzal F12, makalo to ako len mohlo,
ale stabilne. Ked som pustil,
tak dalsich 10s to este cvicilo a potom klud]

3.) zaver: az taky deterministicky sposob ako zabit KDe to zase nebude.

[Semo]

A este je zaujimave, ze ked mam nastavenu prihladnost podla teba, tak glxgears mi dava asi 9x horsi vysledok, nez ked sa podobne uchylaciny vobec nepouzivaju. A to pri tom s nicim nehybem, okna len tak staticky lezia.

[Luboš Doležel (Doli)]

To je ten bug, co jsem reportoval já. Je zajímavé, že ta chyba se za posledních pár verzí několikrát změnila - mně už KWin nikdy nepadá, ale někomu třeba jo.

[Espinosa]

Tak jeste jedno zajimave HOWTO:

http://www.kde.me.uk/index.php?page=x-6.8-xcomposite-howto

Za link diky LuCKymu. Nicemene se jedna o clanecek znacne zastaraly. Pokud pouzivate KDE, pouzivejte kompmgr a ne xcompmgr. Kompilovat nic nemusite, vse uz je davno soucasti distribuci a standardne v Xorg ci KDE.