X Window System slaví 30 let (diskuse)

[leoš]

Ze čtyř námětů na zprávičky ze včerejška byl uplatněn pouze jeden jediný a to ještě pozdě. Stále zbývají tyto tři:

1) Byl odhalen tajný seznam patentů, kterými chce Microsoft zaútočit na Android

2) Je nový Fedora Project Leader

3) Ukázalo se, že Nokia v r. 2008 zaplatila výkupné ve výši několika mil. eur za šifrovací klíč

[R]

choť topiče

[ced]

Co s tím má společného žena pracovníka na pozici manažera tepelných výměníků?

[Punny]

+1

[prcek]

-1

[mankind_boost]

+3.14

[Petr Tomášek]

Pěkná spodoba

[Luboš Doležel (Doli)]

Pokud o ně tak moc toužíte, tak je zadejte sám. Ta poslední ani nevím, jak se týká Linuxu.

[anon]

dejte mu konecne ban

[Roslav]

Povedal by som, ze po 30 rokoch by uz mohol ist do dochodku.

[Peter Golis]

Tak ho nepoužívaj.

[frdrx]

Však už to snad bude brzo. Ta omezení plynoucí z toho, že stále nemáme náhradu jsou už dost trapná a bolestivá.

[R]

Onedlho bude systemd-wayland...

[frdrx]

Pokud by to dávalo smysl, neviděl bych důvod se tomu bránit. S největší pravděpodobností ho to nedává stejně jako systemd-emacs.

[Petr Tomášek]

Jo, a Wayland má být jako dobrá náhrada? Vtipálku...

[frdrx]

Ano, zcela vážně. Wayland bude nejen dobrá, ale vynikající dlouhodobá náhrada. Přinese kromě přehledného, méně objemného a udržovatelného kódu, kterému skutečně někdo rozumí, snazší vývoj např. ovladačů a window managerů, i zvýšení výkonu, bezpečnosti a spolehlivosti. X Window System je monstrum, které si zaslouží zemřít. To není z mojí hlavy, ale z hlav vývojářů, kteří na X, Waylandu, ovladačích, kompozitorech a čímkoli co má co do činění s grafickým rozhraním obecně. Stačí nebýt ignorant a trochu se zajímat.

[Peter Golis]

A aby to bola pravda, tak si všetci pôjdeme kúpiť nové počítače z jediného správneho zoznamu podporovaných zariadení Waylandom. Už taký zoznam existuje?

[Josef Kufner]

Wayland používá KMS a drivery v jádře, takže pokud na daném hardwaru funguje KMS, měl by fungovat i Wayland.

[Michal Kubeček]

…a pokud nefunguje, bude mít brzy problémy i s X.org (pokud je nemá už teď).

[Peter Golis]

Aha. Takže napríklad 3d akcelerácia je už v kerneli. Tssss, tssssss ...

[JoHnY3]

Wayland nepotrebuje 3D akceleraci, pouziti EGL jen proste na vetsine zarizeni dava smysl.

Vypada tohle jako, ze se pouziva nejaka GL akcelerace? Weston jako client bezi na HW specific backendu pro RPi a zadny 3D neni v dohledu: $ ./autogen.sh --prefix=$WLD \ --disable-x11-compositor --disable-drm-compositor \ --disable-wayland-compositor \ --enable-weston-launch --disable-simple-egl-clients --disable-egl \ --disable-libunwind --disable-colord --disable-resize-optimization \ --disable-xwayland-test --with-cairo=image \ WESTON_NATIVE_BACKEND="rpi-backend.so"

[Peter Golis]

Problém je ale v tom, že moderné grafické prostredia vyžadujú 3d. Tým pádom je Wayland bez 3d len slepou vetvou vývoja.

[Josef Kufner]

Kdepak, stačí 2D akcelerace. Například v KDE si v nastavení desktopových efektů můžeš vybrat, zda okna renderovat pomocí OpenGL nebo XRender. A právě 2D akcelerace je to, na čem celá podstata Waylandu stojí – manipulace s 2D buffery.

Kdysi dávno hardwarová akcelerace vykreslování spočívala v hardwarové implementaci kreslení různých geometrických útvarů do framebufferu grafické karty. Proto také Xlib obsahuje spoustu funkcí pro jejich kreslení. Současný hardware oproti tomu tuto podporu již neobsahuje a místo toho umí efektivně pracovat s výřezy obrazovky a pokročilé kreslení se přesunulo do 3D akcelerace a hlavně do knihoven (tedy pryč z hardwaru).

Už tehdy však X Window obsahovalo možnost zapnutí Shadow bufferingu (nebo tak nějak), což bylo o tom, že okna se kreslila do off-screen bufferu a odtamtud teprve šla na obrazovku (zhruba). Výhodou takového přístupu je, že při přesunu nebo odkrytí okna jej není potřeba znovu překreslovat. Tehdy však bylo paměti málo. Moje 386 má 1MB grafické paměti, což nestačí ani na samotnou obrazovku v plných barvách a rozlišení, které ta karta zvládá. Takže proto byla tato volba snad vždy vypnutá.

Současný hardware má paměti, že neví co s ní a hardware umí s grafickou pamětí kouzlit mnohem více než jen určit offset od kterého se bude kreslit (tak byl v dobách 8/16 bitů implementová posun ve hrách). Takže dnes už dává smysl kreslit do off-screen bufferu a nechat hardware ať to poskládá jak je zrovna potřeba. A přesně to dělá Wayland. Vlastně jde jen o reinkarnaci té stařičké volby v X serveru.

Když se před lety zrodily compository, bylo to na nápadu kreslit okna do textur a použít 3D akceleraci k jejich poskládání na displej. Je to v podstatě stejný přístup, ale na jiné technologii. Z pohledu aplikace je to jedno – v obou případech kreslí na 2D plochu. Pořád to ale jde skrz X server, který z výsledné pixmapy udělá texturu a tu teprve vykreslí. Tyto compository závisí právě na hardwarové implementaci této operace a proto nefungují všude.

Wayland však dělá to, že aplikaci předá přímo buffer na kreslení, tedy že přemapuje kus grafické paměti přímo do prostoru aplikace. Tím odpadne nutnost posílat kreslicí příkazy skrz X server a celý proces se redukuje na přístup do sdílené paměti (zjednodušeně řečeno). Ve výsledku aplikace stále kreslí do 2D bufferu a může jí být jedno, co je zač, ale díky vynechání mezikroku je to rychlejší. Compositor pak jen řekne grafické kartě "tento kus paměti patří na tamto místo na obrazovce" a je nakresleno.

Takže i když je možné ten kus paměti taktéž nechat zkonvertovat na texturu a umístit do prostoru, není to nijak potřeba a celý návrh Waylandu stojí jen na 2D akceleraci.

[R]

Starsie karty nevedia takto "skladat" obraz z kuskov. Maju framebuffer, ktory sa zobrazuje a nad nim robit operacie, napr. bitblt. Windows GUI na takomto HW chodi pekne, X11 hrozne (zbytocne prekresluje nezmenene okna). Je s tym vobec Wayland kompatibilny?

[JoHnY3]

Jak pise Josef a mozna trochu zjednodusene: To jak vnitrne funguji client a server povidajici si wayland protokolem pomoci libwayland je ciste jejich vec a je to jedna z nejvetsich vyhod Waylandu. Az za 5-10 let budeme mit OpenGL Restarted 1.4, Mantle 3.0, oepnCuda 19.6 a ja nevim co dalsiho, tak wayland bude porad fungovat.

Pro zajimavost bych dodal, ze MS to od zavedeni WDDM driveru pro grafarny dela docela podobne. Obdoba waylandu je spojena s dalsimic vecmi, ale mechanismus jak se dostava infromace z programu na obrazovku je skoro uplne stejny. Aplikace ma svuj vlastni kus pameti kam maluje pomoci GDI, GDI+, Direct3D, Direct2D... Desktop Window Manager ze vseho slozi obraz a skrz DirectX a WDDM driver to nakonec dostane na obrazvku. Od Win8 existuje jeste WARP (Windows Advanced Rasterization Platform), coz neni nic jinyho nez spesl SW implementace DirectX, ktera funguje jako fallback pokud z nejakeho duvodu nejde pouzit WDDM. MS sel v tomhle pripade 3D cestou, ale DX 12 uz mozna nebude jen 3D API, ale spis obecne graficko matematicke API. Tohle uz castecne plni DX11.

PS: Pokud tu nekdo opravdu rozumi grafickemu stacku Windows, tak piste a kritizujte. Podle MSDN je to cele krapet slozitejsi a protoze jsem na Windows nikdy nic nevyvijel, tak muzu byt misty mimo. Ono to same plati vlasne i o Waylandu :o).

[Petr Ježek]

To mi uniklo. Takže velká gratulace, protože bez Xorg by linux dosud v GUI nefugoval, již jen pro nekonečné množství podporovaných zařízení. Pokud bude nahrazen Waylandem či Mirem, pak tak nejdříve za pět let, až se dodálá nekonečná spousta práce pro zahrnutí podpory pro všechna ta různoradá a různě letitá zařízení. Jen hlupci na něj plivou jedové sliny, aniž by pro věc něco udělali.

[tuxmartin]

Zkousel nekdo pri tom vyroci spocitat vsechny "goto" ve zdrojakach?

https://pbs.twimg.com/media/BWLcY7LCAAEhTap.png:large

[frdrx]

A tohle je ten nejmenší problém.

[pavlix]

Co je špatného na goto, vždyť se používá i v nových zdrojácích. Člověk se nesmí nechat vyvést z míry turbopascalskými teoretiky ;).

[Jakub Galgonek]

Občas je jeho použití na úkor přehlednosti. Docela se mi líbí, jak to v Javě (částečně) vyřešili pomocí continue a break.

[mich]

C má taky continue a break...

[Jakub Galgonek]

Jasně, ale v Javě se dají navíc použít na smyčky s návěstím.

[pavlix]

Občas je jeho použití na úkor přehlednosti.

To stejné platí i pro jeho nepoužití.

Docela se mi líbí, jak to v Javě (částečně) vyřešili pomocí continue a break.

Java má především výjimky.

[Josef Kufner]

Docela se mi líbí, jak to v Javě (částečně) vyřešili pomocí continue a break.

Java má především výjimky.

Tak, tak. A C++ a PHP je má taky. Šetří to spoustu starostí a velmi zpřehledňuje kód.

[Jakub Galgonek]

Tak, tak. A C++ a PHP je má taky. Šetří to spoustu starostí a velmi zpřehledňuje kód.

To ano, ale zase řešit něco takového pomocí výjimky by mi přišlo docela overkill:

loop: while(cnd1) {
  while(cnd2) {
    while(cnd3) {
      if(cnd4)
        break loop;
    }
  }
}

[pavlix]

Nemá smysl posuzovat takovýto umělý pseudokód.

[Jakub Galgonek]

Tebe nikdy neštvalo, že v C/C++ nemůžeš z vnitřní smyčky breaknout vnější?

[Bedňa]

[Ondrej 'SanTiago' Zajicek]

Nestvalo, proste pouziju goto.

[Jakub Galgonek]

Až na to, že tohle bylo o tom, jak se goto vyhnout

[Bedňa]

return

[pavlix]

Tebe nikdy neštvalo, že v C/C++ nemůžeš z vnitřní smyčky breaknout vnější?

Nepamatuju si reálný případ, kde bych to chtěl v céčku udělat, a kdyby na to došlo, považoval bych céčkovský goto za srozumitelnější. Běžně nepíšu v C++, na druhou stranu předpokládám (a trochu jsem googlil), že je tam kolize mezi goto a RAII/výjimkami řešená.

Až na to, že tohle bylo o tom, jak se goto vyhnout

K tomu osobně nevidím důvod.

[little.owl]

Šetří to spoustu starostí a velmi zpřehledňuje kód.

A nove vytvari a muze zneprehlednit data flow.

[pavlix]

Tak, tak. A C++ a PHP je má taky. Šetří to spoustu starostí a velmi zpřehledňuje kód.

To asi nebylo úplně předmětem diskuze. Spíše šlo o to, že pokud používané prostředky využívají mechanismu výjimek (což v C++ není zdaleka samozřejmost a k PHP se radši ani nevyjadřuju), tak už není k použití javovských skoků moc příležitostí. Nejsem si jistý, zda se vůbec jedná o užitečnou vlastnost.

[Josef Kufner]

S výjimkami padá jeden ze dvou důvodů k použití goto: při neúspěchu skok na konec k uvolnění alokovaných prostředků.

Break vnějšího cyklu z vnitřního to však neřeší, ale to naštěstí není příliš častý případ. Na procházení vícerozměrných struktur je většinou stejně vhodnější rekurze a tam už goto nepomůže tak jako tak. Leda by se použil longjmp, ale to už je úplná prasárna.

[BigBoss]

Já jsem goto použil poprvé po 10 letech a snad naposledy v C# minlý týden. Protože MS jsou magoři a switch case :)

[Roslav]

Ale to je dane historickym vyvojom C# a nie je to take goto, ako sa bezne pouziva, ale take speciane switchove, ked este C# nepoznal falltruogh (case bez break, nie som si isty, ci sa vobec da spravit case bez break). Bohuzial si nespomeniem na zdroj, co toto rozoberal.

[Michal Kubeček]

Your point?

mike@unicorn:~/work/git/kernel-upstream> grep -Hr goto * | wc -l
118343

[frdrx]

Jen si dovolím dodat zajímavé počtení.

[Michal Kubeček]

Přesně tak. A na tom screenshotu odkazovaném nahoře vidím jen "goto done" a "goto out", takže jde s největší pravděpodobností o stejný případ.

[Bedňa]

Na základe počtu použitých príkazov by sa kvalita kódu určite nemala hodnotiť.

Je to o štýle zvyku, osobne kód s goto a brakedance nemám rád, ale to bude zvykom, že skôr pozerám do kódu vyšších programovacích jazykov. Pripomína mi JMP zo strojákov.