abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 13:55 | Nová verze

Byla vydána verze 15.0 na Debianu založené linuxové distribuce Untangle NG Firewall. Přehled novinek v poznámkách k vydání a ve videu na YouTube. Vyzkoušet lze (zatím neaktualizované) demo webového rozhraní.

Ladislav Hagara | Komentářů: 0
včera 12:11 | Pozvánky

Letošní ročník konference LinuxDays se uskuteční o víkendu 3. a 4. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během devátého ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru nebo Facebooku, přidat se můžete také do telegramové diskusní skupiny.

Petr Krčmář | Komentářů: 1
včera 10:22 | Zajímavý článek

Alexander Popov se v příspěvku na svém blogu podrobně věnuje možnostem zneužití bezpečnostní chyby CVE-2019-18683 v linuxovém podsystému V4L2. Videoukázka eskalace práv na YouTube. Chyba byla v upstreamu opravena v listopadu loňského roku. Alexander Popov se chybě věnoval ve své přednášce (pdf) na konferenci OffensiveCon 2020.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Nová verze

Byla vydána nová verze 20.02.17 svobodného multiplatformního video editoru Shotcut (Wikipedie). Přehled novinek v oznámení o vydání. Využíván je MLT Multimedia Framework 6.20.0 a WebVfx 1.2.0. Nejnovější Shotcut je k dispozici také ve formátech AppImage, Flatpak i Snap.

Ladislav Hagara | Komentářů: 2
18.2. 16:22 | IT novinky

Spolkový úřad pro informační bezpečnost (Bundesamt für Sicherheit in der Informationstechnik) schválil používání softwarů Gpg4win a Gpg4KDE, tj. nadstaveb nad GnuPG, pro šifrování a přenos utajovaných informací stupně utajení Vyhrazené (VS-NUR FÜR DEN DIENSTGEBRAUCH (VS-NfD)), EU RESTRICTED a NATO RESTRICTED [reddit].

Ladislav Hagara | Komentářů: 0
18.2. 12:44 | Humor

Viceprezident společnosti Oracle Matthew O'Keefe napsal na Twitteru: "Kdyby databáze Oracle neexistovala, světová ekonomika by se zastavila. Kdyby většina open source distribuovaných databází neexistovala, byl by svět pro data mnohem bezpečnějším místem". Příspěvek rozpoutal diskusi nejenom na redditu a následně byl z Twitteru smazán (Wayback Machine).

Ladislav Hagara | Komentářů: 17
18.2. 09:33 | Nová verze

Byla vydána nová verze 1.38 správce síťových připojení ConnMan (Wikipedie). Z novinek lze zdůraznit podporu WireGuardu.

Ladislav Hagara | Komentářů: 0
18.2. 06:00 | Zajímavý projekt

Byl spuštěn Humble Book Bundle: Cybersecurity 2020 by Wiley. Za 1 euro a více lze koupit 7 elektronických knih, za 7,50 eur a více lze koupit 13 elektronických knih a za 13,50 eur a více lze koupit 20 elektronických knih věnovaných kybernetické bezpečnosti od nakladatelství Wiley. Peníze lze libovolně rozdělit mezi nakladatelství Wiley, Humble Bundle, Electronic Frontier Foundation a Let's Encrypt.

Ladislav Hagara | Komentářů: 0
17.2. 21:55 | Zajímavý článek

Clear Linux je distribuce vyvíjená firmou Intel; vybočuje optimalizací na výkon, pročež se používá např. k běhu benchmarků, ale také pro vývojáře či do cloudu. Recenze na Ars Technica se zaobírá použitím Clear Linuxu jako uživatel: instalace, pozorování rychlosti spouštění Gimpu, správa balíčků a instalace Google Chrome nebo konfigurace OpenZFS. Praktické nasazení mimo specializace, kde je výkon kritický, nakonec nedoporučuje.

Fluttershy, yay! | Komentářů: 5
17.2. 21:44 | Nasazení Linuxu

Jižní Korea se z historických důvodů potýká se silnou závislostí na Microsoftu (konkrétně ActiveX), kterou se snaží postupně odbourat. Na jaře 2019 tamní ministerstvo vnitra oznámilo testování Linuxu na pracovních stanicích. Nyní, po skončení podpory Windows 7, byl přechod potvrzen s cílem omezit závislost na třetí straně a snížit náklady. Do roku 2026 je v plánu, že uživatelé budou používat notebooky s Windows, ale připojovat se na vzdálený linuxový desktop v cloudu. Některá ministerstva již Linux používají.

Fluttershy, yay! | Komentářů: 0
Vydržela vám novoroční předsevzetí?
 (9%)
 (6%)
 (3%)
 (82%)
Celkem 161 hlasů
 Komentářů: 0
Rozcestník

Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

19.8.2009 17:01 | Přečteno: 3388× | desktop linux | poslední úprava: 28.8.2009 03:58

Tento příspěvek vznikl původně jako odpověď do diskuse o stavu Intel driveru v Xorg. O jeho nepříliš utěšeném stavu. Téma se nevyhnutelně posunulo i do otázek, jak je to možné, kdo za to může, o situaci u jiných driverů, Xorg a linuxového GUI obecně. Jako tradičně se mi odpověď nafoukla a tak mi přišlo ji nechat jen jako text pohřbený hluboko v diskusi. Chci se zmínit o svých současných převažujících pozitivních zkušenostech s Nvidia driverem, ale nevynechat ani problémy z nedávné minulosti s open source drivery a zastat se uživatelů Intel karet. Jejich problémy mi nejsou lhostejné. Ani obecné problémy a směřování Xorg. Zmiňuji věci na samé hranici svých technických znalostí – X11 protokol, asynchronní a synchronní protokol a jeho vliv na UI a řešení od Gtk a Qt – Nechť jsou mí případní učenější kritici shovívaví. Vyjádřím se k oblíbeným tématům o financování a desktop versus server.

Zamyšlení nad příčiny současného stavu linuxového GUI - Xorg, X11, Drivery

U mě OK...

Jsem spokojeným uživatelem Nvidie a Linuxu. Osobně si nemám na co stěžovat. Jak v klasickém tak (akcelerovaném) kompozitním desktopu. Osobně se pamatuji, že krátce v dřevních dobách Compizu byl resize trhaný, a byly tady podobné výtky proti Kwin, ty už jsem na vlastní oči neviděl. Pro mě něco stále něco jako zprávy o pozorování UFO. Nějaké problémy s distribucí?

Nevím jaký důkaz by postačoval, snímač obrazovky je blbost, má příliš vysokou vlastní režii než aby něco prokázal. Snad jedině se natočit DV kamerou, má to dostatečné FPS a ne-synchronnost s LCD monitorem by snad nebyla takový problém. A pak to sestříhat, transcodovat a pověsit na web (youtube?). Hm, dost práce, já mám nesestříhaného videa asi tak na dva roky zpátky :(

Linux není rozhodně jediný, kdo nějaké problémy s moderním kompozitním desktopem má. Windows Vista, které přišli na jednom z mých notebooků (HP DV2000, NVidia Go 72000) byl právě výkon nvidia driverů katastrofa! UI padalo, doslova se rozsypalo, viz přiložený obrázek, hodně SW nechodilo - hry, VLC. Oproti tomu je výkon na Linuxu - balada! Abych si mohl zahrát oblíbenou multiplatformní hru TC:E, musel jsem si nainstalovat Linux. Bezesrandy.

..a není to tak úplně OK

Ale dost chvály, otočme minci. Výkon je u mě v pohodě, spokojenost. Ale jinak musím dát zapravdu kritikům, stav linuxového GUI není ideální. Dlouho jsem byl uživatelem karty Radeon Mobile 7500 a open source driverů (pro tuhle kartu bohužel nejsou jiné) a tam bylo ke spokojenosti daleko. podrobnosti tady a tady. Bugy, špatný výkon jak v klasickém tak kompozitním desktopu, artefakty hlavně u OOo, překreslování obsahu oken viditelné, nepoužitelné XAA i EXA, bug #1424 v renderingu fontů způsobující praktickou nepoužitelnost RenderAccel atd. (to je zajímavý přímo typový případ – chystám pro něj samostatný článek, ten si ho zaslouží)

Zpět do současnosti. Dokonce i na novém počítači je stále patrné překreslování obsahu některých oken a to mám, opakuji, Nvidii a moderní výkonný počítač koupený letos. V roce 2009 bych očekával že alespoň taková základní věc bude vyřešená. Tohle měli vyřešené už Windows 95. To je vážení téměř patnáct let! U Windows 95 si nepamatuji, že bych viděl překreslující se okno nativní aplikace a to i bez akcelerovaného desktopu. Hádám na dotažený dotažený kompozitní manažer i bez podpory OpenGL nebo DirectX či vůbec nějaké hlubší HW podpory. I tenhle problém je zajímavý, taky by si zasloužil samostatný článek.

Je to drobnost, trochu to kazí profesionální pocit z desktopu, ale v práci to nijak nevadí, na rychlém počítači je to na hranici pozorování a hlavně, při použití kompozitního windows manageru tenhle problém zcela mizí.

Drobnost ale není co čtu o stavu Intel driveru a některých dalších open source driverech. Slabý výkon, pády, mrznutí. Na jednu stranu dva výrobci ze třech existujících (víceméně) mají dobrou až výbornou podporu linuxu/Xorg. To není tak zlé. Bohužel většina notebooků má dnes integrovanou grafiku od Intelu. NVidia si jde vlastní cestou, řadu technologií si implementovali po svém, naštěstí se stejným interface, jako například DRI nebo AIGLX. Soustředili se primárně na tvorbu nového driveru, méně na tvorbu nových technologií. Ano, bohužel není to open source.

Lavice obžalovaných se představuje

Část viny za situaci určitě nese Intel sám. Někteří kolegové mají tendenci se ho zastávat na úkor, řekněme Xorg. To není spravedlivé. Lidé najatí Intelem vytváří drivery. Intel platí další lidi v Xorg a má výrazný vliv na jeho vývoj, jmenovitě Keith Packard, to je prominentní vývojář. Intel je asi nejdůležitější významná komerční firma stojící za vývojem Xorg. Pikantní je na to, že právě Xorg Intel driver měl být technologický „show piece“, jak Intelu tak open source obecně. A je všechno jen ne to, alespoň ne v pozitivním slova smyslu. Pikatní je na tom, že Intel driver je jeden z mála open source driverů. Žádné argumenty výmluv na zlé výrobce hardwaru tající specifikaci tady nejdou použít. Specifikace je známá, veřejná, Intel implementaci podporuje a to aktivně, vynakládá na vývoj vlastní prostředky.

Část viny za situaci určitě nese Xorg a vůbec celá architektura X11. Poslední hlubší revize X11 je cca z roku 1988 (?)! To je na něm samozřejmě znát. V době před dvaceti lety nikdo nečekal, že uživatelé budou chtít plynulý resize okna s plným viditelným obsahem okna. To jsem poprvé viděl až u Windows95 (98?) o deset let později. Priority byly jinde, například na síťové transparenci, představy a stylu používání byli jinde (dedikovaný X server a stanice, oddělené železo), nároky aplikací byly jinde.

Trochu jsem zapátral v technických podrobnostech X11: Kvůli podpoře síťové komunikace X11 protokol je asynchronní. Kvůli tomu nemá obsah okna takovou kontrolu nad vlastním vykreslováním jako u synchronních protokolu - Windows a Mac. Nevýhoda asynchronního přístupu se zřetelně negativně projevuje právě u resize okna se zobrazením obsahu. Proto je tato funkcionalita tak problematická v linuxovém/unixovém UI. Je opakovaně zmiňovaná v diskusích, dávaná jako typický příklad neefektivity (nespravedlivě celého) linuxového desktopu.

Pokud vím, GTK to řeší (řešilo?) masivním zasíláním příkazů repaint, dokonce i pro neviditelné widgety místo zdlouhavého zjišťování, která část okna je viditelná. To sice zlepší user feel z resize, ale má vedlejší defekty - přetěžování X11, nesmyslné operace, komplikuje to jiné optimalizace. Ano, tohle je „hack“.

Vývojáři Qt šli trochu jinou cestou, v současnosti vím o pokusech využít _NET_WM_SYNC_REQUEST protokol a dočasně zesychronizovat komunikaci. Není to hack, ale oficiální, leč mladá, extension. Jestli správně chápu, je to stále ve vývoji a reakce na první implementaci jsou rozporuplné. Podrobnosti viz smooth-and-solid-resizing-on-x11 na trolltech Qt blogu.

Troufám si tvrdit, že Unixové dědictví a taky lpění na paradigmatech 20 let starých je tady spíše na překážku. U Applu, jinak taky unix like systému s windows serverem, uplatňují mnohem pragmatičtější přístup k prospěchu jejich i jejich uživatelů. Monolitismus Xorg. Taky je otázka, zda vývoj intel driveru není příliš prorostlý s vývojem celého Xorg. Drivery Nvidia a ATI jsou výrazně samostatné projekty a zdá se, že jim to svědčí.

A v neposlední řadě je to otázka financování. Linux desktop prostě nevydělává. Nevydělává dost ani na svůj vývoj. Živí ho komerčně úspěšný serverový sektor, tam ale potřeby GUI jsou minimální až žádné. Pokud je Xorg vůbec nasazen, pak základní VESA režim je víc než postačující. Xorg není hobby projekt pro volné večery, to chce hodně dobře placených vývojářů. Investoři, ono jich v začátcích XFree86 a Xorg zase tak málo nebylo, většinou prchli, mají vlastní potiže, zkrachovali; nové odrazuje nejistý komerční úspěch s roztříštěným, nejednotným systémem, duplikované projekty ("kanibalismus"), rozhádaní vývojáři a mraky distribucí a jejich počet roste. Na serveru to zase tak nevadí u desktopové stanice mhohem víc. (počet stanic >> počet serverů, technická zdatnost aminů >> technická zdatnost BFU, náročnost vývoje GUI rozhraní >> náročnost vývoje CLI rozhraní, počet aplikací a nástrojů na desktopu >> počet aplikací a nástrojů na serveru atd.).

Nějaké návrhy?

Bez Xorg se neobejdeme, pokusy rozjet konkurenční projekty neblaze ztroskotaly (Y, Xgl, Xegl). Je to příliš komplexní záležitost. Vyvíjet nový okenní systém je práce na roky pro rozsáhlý, jednotný, dobře organizovaný team, dobře placených vývojářů a testerů. Vyprávět by mohli i u Microsoftu, viz roky (?) odkládaná Vista, odkládaná právě i kvůli potížím s vývojem nového DWM, a pak neslavné začátky a neustále dolaďování a sliby, že Windows 7 už bude OK.

Troufám si navrhovat – nezahazovat Xorg, ale raději nebát se se zrevidovat X protokol pokud někde nedostačuje, specializovat ho, nabídnou podporu alternativ vhodnějších pro současný styl používání UI – volitelně synchronní protokol, volitelné vyloučení síťové vrstvy. Mimochodem, kolik z X11 protokolu skutečně moderní desktopy (KDE, Gnome) používají. Je to jen nějaký subset? Například X11 sice umožňuje vykreslit text přímo, ale nikdo to nepoužívá, možná nějaké dřevní X aplikace 10 – 20 let stará. Moderní frameworky si renderují text sami, s použitím FreeType2 knihovny a XRender extension. Díky tomu máme kvalitní anti-aliasing. Nestálo by za to takové „mrtvé“ části X11 zrevidovat a vyškrtat?

Nějaké omluvenky?

Taky vezměme v úvahu, že desktopový linux je z trojlístku používaných desktopových OS nejmladší. Je to sporné, ale Windows jako seriózní desktopový systém považoval tak od 3.11 a Linux tak od roku 2000. Apple má kořeny ještě starší. To se také musí někde projevit.

Je to i otázka komunity, podívejte se, kolik lidí tady na abclinuxu používá Xka leda tak pro xterm a ještě se bijí v prsa, jací to jsou machři, že jim stačí příkazová řádka. S takovou komunitou se dobré UI buduje špatně.

Při zvážení situace musím konstatovat, že to Xorg a linuxové desktop vlastně dotáhl TAK DALEKO! Tomu všemu vyjmenovanému navzdory. Mám ke všem zůčastněným hluboký respekt.


Dodatek 1:
Adresa zprávičky:
http://www.abclinuxu.cz/zpravicky/o-grafickych-ovladacich-intel-kms-a-x.org
Adresa originální odpovědi (75% textu stejné):
http://www.abclinuxu.cz/zpravicky/o-grafickych-ovladacich-intel-kms-a-x.org/diskuse#6
http://www.abclinuxu.cz/zpravicky/o-grafickych-ovladacich-intel-kms-a-x.org/diskuse#11




Update1:
Obrázek 1. - ukazuje rozpadlé Visty, to je zjevné. Foto ve fotce je vlastní, z cest.
Obrázek 2. - ukazuje defekty zase v Xorg, viditelné poškození obsahu okna při přejezdu jiným oknem. Aby to bylo patrnější, dal jsem několik oken na sebe a rychle přes ně přejel jiným. It is not so easy to take a snapshot of it (překlad??). Připravuji o tom samostatný příspěvek, už asi dva roky.


Update2 (28.8.2009):
Děkuji všem zůčastněným v diskusi. Mám radost, že článek vzbudil takový ohlas a že se diskuse udržela věcná a k tématu. Jedu teď na kratší dovolenou, tak se tu dobře bavte bezemě ;-)
       

Hodnocení: 96 %

        špatnédobré        

Obrázky

Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery, obrázek 1 Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery, obrázek 2

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

Jan Drábek avatar 19.8.2009 17:28 Jan Drábek | skóre: 41 | blog: Tartar | Brno
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Dobrý zápisek, s většinou musím souhlasit.

(u mě je stav intel i nvidia driverů podobný - občas se vyskytne chyba při překreslení, občas to shodí Xserver).

01010010 01000101 01010000 01101100 01001001 00110010 01000100 01100101 01010110
19.8.2009 17:37 Roger
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Mne to neda se Intelu nezastat. Jak sam uvadis, Intel investuje do vyvoje Xorg (pomerove) nejvic penez, jeho vyvojari stoji za vecmi jako GEM a KMS. Bohuzel i pres svou velkou snahu a schopnosti proste v tech par lidech (vybavuji se mi jmena asi tri az ctyr lidi, ale nevim, kolik jich je doopravdy) nestihnou pres vikend.

Osobne jsem s ovladaci konecne zase spokojen, KMS funguje, UXA funguje, vsechno beha prijemne rychle (doby ovladacu 1.5 a ukrutne pomale EXA jsou nastesti uz pryc). Nerikam, ze nemam vyhrady - s GEM v jadre je casto odpovedi na nejaky problem "nainstalujte si kernel 2.6.85-rc43 s touhle sadou patchu", coz neni pro normalniho (distribucniho) smrtelnika zrovna pohodlne. Ale snazi se a prave vyrazeni starsich technologii (DRI1, XAA, EXA) jim umozni zmensit mnozstvi kombinaci, ktere budou muset resit.

Vyvoj X rozhodne probiha, bohuzel ne tak rychle, jak bychom doufali - vyvojaru je proste jen hrstka, kod ohromny a slozity.

A co se tech problemu z clanku, na ktery puvodni zpraviccka odkazovala, tyka, casto by se daly shrnout pod "spravci distribuce XY jsou nezodpovedni blbci a davaji uzivatelum nefunkcni ovladace". Kdyz nejake ovladace nefunguji, tak je prece nedam do stabilniho vydani distribuce (ano, myslim tim hlavne Ubuntu 9.04). Jiste, bylo by skvele, kdyby ty ovladace fungovaly vsem a vsude.

A mala perlicka k Windows (jejich rychlost GUI mi imponuje a je vzorem, ke kteremu se snad jednou Linux doplazi) - asi jsem blbej, ale treba vsyncovane video se mi v nich, na rozdil od linuxu, rozbehat nepodarilo (ten tearing me nici).

19.8.2009 18:12 VRtulnikk | skóre: 17 | blog: blogisek | Rokycany
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Já jsem si nikdy ničeho podobného nevšiml a ani nepamatuju, kdy by mi spadl Xorg (aniž by to bylo moji chybou). Občas mi vytuhne FF, Flash, občas Amarok, ale to je asi tak vše, pomalost ani artefakty nepozoruju. Asi jsem šťastný člověk, ale opravdu by mě zajímalo, čím to je. Grafickou kartu mám Nvidia, používám Xfce bez kompozitního manageru.
19.8.2009 22:32 goo_one
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

nVidia 9600GT. Žádný z popisovaných problémů neznám.

19.8.2009 18:16 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
zdravim,

s vetsinou toho, co jste popsal souhlasim a pekne je to popsano.

Tyhle veci uz chteji hodne znalosti.

Kde to vazne a doplneni: - lobbing - prosadit, ze velka firma pusti 1MKc/rok na vyvojare je podle me velky problem. I presto, ze na jinych vecech se vydelalo 100-nasobne.

- chce, to lidi, co znaji. Tech chodi malo po svete. Nebo sehnat nekoho, kdo vidi do "core" uz tak jednoduche take neni.

- hodne aplikaci nepouziva akcelerovane knihovny. Ty knihovny snad jiz jsou a budou -li se vice pouzivat, tak bude i tlak na opravy v nizsi vrstve.

- Obcas mi to prijde, ze nikdo pri testovaci nepouzival velka data. Kdo dela treba velke grafy, tak rychlost neni nic moc. I presto, ze treba ve hrach je to svizne.

- vyvojova prostredi - IDE. Tady je nejvetsi kamen urazu. Velky projekt se v konsoli dela hodne spatne. Zejmena pro zacatecnika v tomto projektu. O chybach IDE a pomalosti sestaveni buildu radeji nemluvit.

- Lide se vzhledli v internetovych prohlizecich. Takze, co nefunguje jinde uz jde lehce stranou.

- linuxovy desktop je vcelku velky problem pro javu. Nekdy by neskodilo nadavat na Xorg misto na javu. Staci se nekdy podivat do Sun-i "bugparady" nebo i na to, co se deje po spusteni aplikace v pocitaci.

- hodne lidi opomiji obecne principy a postupy okolo operacnich systemu. Ono dohledat neco ve stylu jak psat "desktop", "x-server", nebo i textovy editor, neni zcela snadne.

gf
19.8.2009 18:35 Roger
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Nema Swing naaahodou lehce problemy s vykreslovanim? Treba s (ne)pouzivam XRender a sw rasterizaci?

thingie avatar 19.8.2009 18:37 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Swing má problémy většinou úplně se vším, horší šrot aby člověk pohledal. Nebo ne, to je marná práce, swing vede.
Růžové lži.
19.8.2009 20:27 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Co si budeme rikat, tak po par letech clovek zjisti, ze vsechna desktopova prostredi jsou nedodelany srot. Bud to umi skoro vse a obcas to nefunguje, anebo to umi zase moc malo, ale je to vice stabilni.

19.8.2009 20:24 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

toto nevim. Kdytak pohledejte sun-i bugparadu. Je tam toho mraky.

19.8.2009 21:01 Roger
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ehm, to byla spis recnicka otazka :)

http://bugs.sun.com/view_bug.do?bug_id=6307603

http://bugs.sun.com/view_bug.do?bug_id=5086814

19.8.2009 18:18 Zdenek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Rychlost GUI na Windows je dosazena jednoduse tim, ze bezi v kernel modu a navic ma jeste velkou prioritu. A prave proto pise kolega prede mnou, GUI rychle, ale video s tearingem.
19.8.2009 18:31 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jenom tím to rozhodně není. Je to i tím, že to GUI je opravdu moc, moc rychlé – jednoduše má velmi nízkou režii procesoru. Každá běžná akce v GUI sežere ve Windows několikanásobně méně cyklů CPU než tatáž akce pod X.org. To je dobře měřitelné prostým měřičem vytížení CPU. Týká se to prakticky všeho od základů (třeba pohyb myší nebo klávesnicí v něčem) až třeba po vytížení při zobrazování flashového videa.

Video s tearingem ve Windows nemám, protože stejně jako v Linuxu používám ovladač (respektive v přehrávači video výstup) vhodný pro přehrávání videa. To není věc Linuxu nebo Windows, ale ovladače.
Grunt avatar 19.8.2009 19:15 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Rychlost GUI na Windows je dosazena jednoduse tim, ze bezi v kernel modu a navic ma jeste velkou prioritu.
Ano a přesně to je ten důsledek přizpůsobování se BFU jak jsem psal níže a doufám, že k tomu "Linuxový desktop" nikdy nedojde. Protože v případě že ano, tak s ním končím.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
19.8.2009 20:50 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tohle platí pro dnes již v podstatě starý model GDI graphics stacku + XPDM driverů.
U windows Vista a 7 je komplet nový model DWM graphics stack + WDDM drivery. (I když u WDDM 1.1 (windows 7) se objevují některé staré features GDI).
U nového modelu už běží v kernel-mode jen naprosté minumum - tedy DirectX vykreslovací backend a pochopitelně device miniport driver (ta část driveru, která komunikuje přímo s hardwarem). Zpětná kompatibilita s GDI je myslím zachována, nicméně výstup GDI nemíří do hardwaru nýbrž do DirectX backendu, který všecko semele a výsledek pošle miniportu(ům).

V GDI + XPDM generaci bylo bykreslování hodně rychlé a efektivní, to ale bylo dáno jednoduchostí až primitivností onoho modelu.
Co se týče X.orgu, tam naopak můžeme hovořit o přílišné složitosti a komplexnosti řekl bych, což je ale z části relikvie minulosti.

O problémech DWM a WDDM píše částečně už kolega v blogpostu, v každém případě ani na microsoftí straně neprobíhá compozite desktop úplně hladce a bez problémů.
Nutno však poznamenat, že WDDM ačkoli má svoje problému, je jako architektura o dost více KISS než X11. Není nějak výrazně "architekturálně" složitější než předchozí model, byť řeší pokročilé věci jako compoziting, a podporuje i OpenGL, tedy cizí engine. Myslím, že by si X/linux/opensource/freesektop/kdokoli mohli brát příklad. Stačí se mrknout tady a tady...

To, že Windows nejsou vůbec komunitní záležitost má v této situaci jedno velkou výhodu: Jakmile Microsoft zavelí "kompletně měníme graphics stack a display driver model, počítejte s tím", tak nikomu nezbyde než napsat novej driver či prostě aktualizovat svůj SW, protože jinak na nových windows neprorazí. Uživatelé si rozhodně nebudou vypínat compoziting a přeinstalovávat drivery (XPDM je na Vista/w7 stále podporováno, ale jen při vypnutém novém modelu) jen kvůli tomu, že tajhle nějaká aplikace novej model nepodporuje.

Zkrátka tohle ve světě linuxu/unixu nejde - tam když někdo přijde s novým modelem, tak se mu na to všichni vykašlou, jakkoli je ten model lepší než stávající, protože zůstat u toho starého je zkrátka jednoduché, sdnadné, pohodlné :/
Ještě navíc objeví spousta uřvanců kritizujících počáteční problémy různých novot.. (známe to z KDE4, že...)
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
19.8.2009 20:57 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
*vykreslování a *freedesktop
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
thingie avatar 19.8.2009 18:22 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Třeba ty Xkové fonty nebo většinu z kreslícího smetí nepoužívá už prakticky nikdo, ale těžko si to někdo může dovolit vyhodit, protože staré aplikace, to moc řešení není, ono by to ani ničemu nepomohlo.
Růžové lži.
19.8.2009 19:08 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Mnoho terminalovych emulatoru pouziva klasicke Xove fonty. A je to dobre, protoze Intel drivery i dnes vykresluji fonty pres Xrender casto mnohonasobne pomaleji, nez klasickou cestou.

thingie avatar 19.8.2009 19:18 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
No. Jistě. Ale výhra to určitě není. A důvod proč by glyfy přes XRender musely být nějak katastrofálně pomalejší principiálně víceméně neexistuje.
Růžové lži.
19.8.2009 19:25 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Neexistuje. Ale dokud ten Intel ovladac bude takto rozbity, tak jsem rad za ty rychle terminaly.

20.8.2009 05:11 Marex
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Nezkousel ses podivat, jestli treba emacs nema nejaky vlastni graficky server? Pak uz bys mozna ty Xka ani nepotreboval ;-)

20.8.2009 11:13 Ivan
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Tohle opravdu nechapu. Na linuxu mi vzdycky vadilo ze bitmapovy fonty z X11 vypadaji extreme hnusne, a ze v some nemaji diakritiku. Nejak si nezvpominam, ze by mi pred 10ti lety prislo vykreslovani fontu pomaly. Treba prvni verze netscape scrolovali stranky(tehdy jeste bez obrazku) velice ryhle. Mozna si ty stary casy jenom idealizuju. Ale je nejaky duvod proc jsou "akcelerovany" forty tak pomaly?

PS: mam Ati Mobile(neco).

 

20.8.2009 12:20 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Na linuxu mi vzdycky vadilo ze bitmapovy fonty z X11 vypadaji extreme hnusne

To je dost subjektivni, me se nektere bitmapove fonty z X11 (treba misc-fixed) libi vic nez zatim vsechny vektorove fonty podobneho typu.

>, a ze v some nemaji diakritiku.

To uz je davna minulost.

> Ale je nejaky duvod proc jsou "akcelerovany" forty tak pomaly?

I klasicke vykreslovani fontu bylo akcelerovane (pres XAA), akorat neumelo antialiasing a fonty byly ulozene na serveru.

Pres Xrender je mozne vykreslovat fonty ruzne - pomoci A1 glyphsetu (1 bpp neantialiasovane), pomoci A8 glyphsetu (8 bpp, antialiasovane), nebo nevimjak subpixel-antialiasovane.

Do vnitrnosti driveru nevidim, ale asi neni zadny duvod, aby Xrenderem vykreslovane fonty pomoci A1 glyphsetu byly pomalejsi nez klasicke fonty (pro grafickou kartu jde o stejnou operaci). Nicmene v Intelich driverech tomu tak je.

Vykreslovani A8 glyphsetu asi vzdy bude trochu pomalejsi nez vykreslovani A1 glyphsetu, ale pokud se nejedna o grafickou kartu z prvni poloviny devadesatych let (ktera ma akcelerovane A1, ale ne A8), tak by to melo byt tak rychle, ze rozdil nebude vyznamny. Nicmene opet to je pomale vyrazne vic, nez by se dalo cekat.

Pro ilustraci vysledek z x11perfu ns Intel driveru ve verzi 2.6.0 (prvni radek je klasicke kresleni textu, pak XRender A8, XRender A1,  a XRender pro subpixel antialiasing):

80000000 trep @   0.0004 msec (2590000.0/sec): Char in 80-char line (TR 10)
1200000 trep @   0.0305 msec ( 32800.0/sec): Char in 80-char aa line (Charter 10)
8000000 trep @   0.0056 msec (178000.0/sec): Char in 80-char a line (Charter 10)
1200000 trep @   0.0313 msec ( 32000.0/sec): Char in 80-char rgb line (Charter 10)
  

20.8.2009 13:32 Ivan
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ahaa, dik za info. Jestli to dobre chapu tak MS to proste ocural tim ze jejich fonty(treba Verdana) vypadaji dobre pri 96 DPI i bez antialisingu a proto jim staci 1bpp.

 

20.8.2009 16:16 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Myslim, ze ve Windows se antialiasing pouziva. Akorat tam asi nemaji tak rozbite ovladace.

20.8.2009 22:03 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ve Windows umí antialiasing GDI+, ale jedná se čistě o SW knihovnu (která sice používá i GDI, ale tam antialiasing kromě písma není).
20.8.2009 13:21 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jak pango kreslí text, který míchá symboly z různých fontů, používá kerningové páry, dodělává ozdoby k arabskému text apod. Nevede takto složitý proces na přenos bitmapy celého textu z klienta na server? Nevím, jak je na tom Qt teď, ale dřív oproti pangu neumělo ani substituci fontů, za to bylo rychlejší. Není pomalost způsobena tímto?
limit_false avatar 19.8.2009 18:30 limit_false | skóre: 23 | blog: limit_false
Rozbalit Rozbalit vše XRandR

Ze skusenosti musim souhlasit, mam intel X3100 na notebooku cca 2 roky. Snad driver verze 2.2.x byl nejlepsi, pak to slo nejak hodne dolu s vykonem atd.  Posledni ktery jsem zkousel (myslim 2.5.x) jsem musel downgradovat, byl neskutecne pomaly. Nejaky cas uz nove verze radsi ani nezkousim.

Intel driver podporuje XRandR 1.2, nevim jestli a jak moc dobre XRandR podporujou ATI/NVidia drivery (binarni od vyrobce). Vim, ze treba nvidia ma nejakou vlastni utilitu, jenze XRandR se hodi treba v skriptech (casto menim externi displaye, sit, atd. tak to mam vsechno naskriptovano). Taky nvidia TwinView neni Xinerama a nektere aplikace s tim mely problemy (onehda jsem u nvidia driveru musel Xineramu vypnout, protoze to s ni neslapalo).

When people want prime order group, give them prime order group.
19.8.2009 18:42 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Dobrý zápisek. Chce to více takových článků na tato témata.

Polemizoval bych s tvrzením, že „bez Xorg se neobejdeme, pokusy rozjet konkurenční projekty neblaze ztroskotaly (Y, Xgl, Xegl)“. Věci se někdy přihodí rychleji, než by člověk čekal.

Již téměř rok se vyvíjí nový okenní systém Wayland, který dost možná může v budoucnu X11 nahradit. Právě Wayland byl zgruntu navržen tak, aby neměl některé nedostatky, které má X11 vrozené, jako právě to zmiňované nesynchronní měnění velikosti, a hlavně aby byl jednodušší, bez spousty komplexních nánosů, které se v X11 za ty dekády usadily. Stejně tak Google oznámil, že ve svém Chrome OS příští rok bude mít nový okenní systém (ne správce oken, ale okenní systém). A vzhledem k tomu, že na Wayland snad bude portováno i GTK+ atd., řekl bych, že bez X11 se časem klidně obejít můžeme.
19.8.2009 19:39 R
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
GTK s jeho ultrapomalostou to cele zabije :D
20.8.2009 09:17 Murry | skóre: 16 | Brno
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Nevis o tom vice informaci?Je to uz sputitelny (nerikam ze pouzitelny)? Toto by me zajimalo.

20.8.2009 09:43 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Bohužel, informace jsou velmi sporadické. Spoustitelné to už je asi dávno, použitelné ještě ne. Ani ten vývoj asi nebude nějak překotný, v podstatě na tom dělá jenom příležitostně Kristian Høgsberg... On totiž Wayland bude založený na stejných věcech jako moderní X.org/Linux (DRM, KMS, GEM) takže část práce na Waylandu je i práce na té infrastruktuře.

http://groups.google.com/group/wayland-display-server

http://cgit.freedesktop.org/~krh/wayland/
20.8.2009 09:39 Murry | skóre: 16 | Brno
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

tedka jsem nasel na netu nejaky info, dokonce repozity, ale tam je posledni commit 29.5. ale treba byla presunuta, nevim.

stativ avatar 20.8.2009 09:43 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Má to menší problém. Wayland se zas tolik nevyvíjí. Ale četl jsem, že na něj hodlají přeportovat Clutter a snad i Cairo.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
20.8.2009 09:51 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Vyvíjí, ale asi ne moc veřejně. Poslední zpráva od Kristiana je ze srpna, kde píše, že věci jsou zase v pohybu.
stativ avatar 20.8.2009 10:06 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Bezvadné.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
Grunt avatar 19.8.2009 19:06 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Nevím jaký důkaz by postačoval, snímač obrazovky je blbost, má příliš vysokou vlastní režii než aby něco prokázal.
Též jsem nad tím přemýšlel a tento problém mě neuvěřitelně štve. Nedá se k poslednímu bufferu(nejspíše framebuffer) dostat z jiné strany než ze sběrnice a z druhé strany RAMDACem překonvertovaný signál? Třeba některým z těch debugovacích pinů co jsou na kartě?
Například X11 sice umožňuje vykreslit text přímo, ale nikdo to nepoužívá, možná nějaké dřevní X aplikace 10 – 20 let stará. Moderní frameworky si renderují text sami, s použitím FreeType2 knihovny a XRender extension.
Ne, to ani omlem. Ideální cesta by byla kdyby to ten server renderoval s použitím FreeType2 a XRender extension. Napadlo Vás jakou to způsobuje režii? Ano, většina moderních x86 počítačů(čti AMD/Intel dvou-jader) to jistě zvládne levou zadní, ale nádhera GNU/Linuxu je právě v dynamičnosti nasazení i na jiné herky než jsou nejnovější dvou-jadra s tunou volné paměti a rozšířenou instrukční sadou(a co teprve jiné architektury než x86?). A napadlo Vás jak se to bude přenášet po síti? Ano, 99,9% BFU "Linuxového Desktopu" to asi nikdy v životě nevyužije(a tím myslím jak přenos po síti, tak nějakou herku jinou od moderního x86) a to je také důvod proč nechci aby se těch 99,9% BFU do GNU/Linuxu sralo. Chtě nechtě se totiž pro jejich větší úlovky bude muset přizpůsobovat a s ním se budu muset přizpůsobovat já. Napadlo Vás třeba místo renderování na lokálním počítači to posílat po velmi rychlé, nízko-latenční síti(1Gbps) na jinou stanici a renderovat a zároveň nahrávat to z framebufferu to tam? Jak by toto bylo možné, kdyby se Xorg přizpůsobilo právě těm BFU? A navíc já tu funkci používám. A i když asi ne každý den, tak je stále dobré aby existovala pro případy nouze, které mohou nastat. Takže ještě jednou: Ne, ne, ne, dup, dup, dup! Já se přizpůsobovat nechci. Přizpůsobený OS pro ně už existuje a nech si na něm pěkně zůstanou.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
thingie avatar 19.8.2009 19:16 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
No, fonty si rasterizuje klient svoje vlastní, udělá z nich mapu průhlednosti, ta se jednou přenese na X server, tam se kešuje jako pixmapa, a to ee už jenom skládá do textu, pak. Nějaká trošku vyšší režie tam bude, ale že by to bylo nějak hrozné, aby bylo třeba malovat katastrofické vize jakože to pak nepude na ničem pod čtyřjádrový Intel, to jako absolutně ne.
Růžové lži.
Grunt avatar 19.8.2009 19:19 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

To byla jen ukázka. Dejte jim prstíček…

A co síť? Jaký bude rozdíl režie po síti když scrolluju třeba nějakou knihu s malým fontem ve full-screnu? Já si myslím, že ten rozdíl, pár komprimovaných písmenek vs. posílání kompletně celé obrazovky x-krát za sekundu po síti už nebude takový pakatel.

Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
thingie avatar 19.8.2009 19:22 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Celou obrazovku bych musel posílat, kdybych si komplet vykreslil všechno u klienta, a pak to jako pixmapu posílal na server, což právě s XRenderem nedělám. I tady je to samozřejmě o trochu víc, než v případě X fontů, ale furt, není to žádný nárůst tisíckrát, neroste to nikam do nějaké úplně jiné třídy, je to furt jenom o trochu víc, prostě.
Růžové lži.
19.8.2009 19:24 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Viz muj mail niz (a v podstate i prispevek thingieho) - pri pouzivani Xrenderu se glyphset (vyrenderovany font) nahraje jen jednou, pak se posilaji jen cisla znaku. Takze pri scrollovani knihy s maym fontem bude ten provoz vicemene stejny jako u klasicke metody.

Takze tve obavy pochazeji z nepochopeni toho, jak renderovani textu pres Xrender funguje.

Grunt avatar 19.8.2009 19:32 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Takze tve obavy pochazeji z nepochopeni toho, jak renderovani textu pres Xrender funguje.
Přesně. A proto mám také strach. Stejně by mi byli milejší písmenka než nějaké symboly.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Grunt avatar 19.8.2009 19:33 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Sakra, oprava:

Přesně. Nikde netvrdím, že tomu rozumím(určitě ne na takové úrovni). A proto mám také strach. Stejně by mi byli milejší písmenka než nějaké symboly.

Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
19.8.2009 19:21 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Napadlo Vás jakou to způsobuje režii?

Minimalni. Protoze vyrenderovane glyphy staci prenest na Xserver jednou pro cely desktop (pokud se pouzivaji vsude stejne fonty a toolkity se dohodnou na konvenci sdileni fontu).

Nekde jsem cetl nejake srovnani, ktere ukazovalo, ze preneseni vyrenderovanych glyphu z klienta na server neni zas o tolik drazsi nez preneseni metrik z X serveru na klienta (coz je treba delat u klasickych Xovych fontu). A zatimco preneseni glyphu staci udelat jednou pro cely desktop, prenaset metriky je treba pro kazdeho klienta.

A pokud by te trapilo vypocetni narocnost klientskeho renderovani fontu do glyphu, tak je mozne to nedelat a misto toho pouzit client-side bitmapove fonty, pripadne mit na disku nacachovane vyrenderovane vektorove fonty (bitmapove fonty vznikle vyrenderovanim vektorovych).

Tedy i pri kresleni pres Xrender je mozne pouzivat bitmapove, neantialiasovane fonty, efektivita sitove komunikace az na uvodni preneseni glyphsetu je vicemene stejna (znaky pro kresleni se predavaji jaky indexy do glyphsetu).

Existuji asi dva duvody, v cem jsou klasicke fonty dnes lepsi:

1) je to jednodussi na programovani - staci zadat jmeno fontu a neni treba se starat, kde k fontu prijit.

2) soucasne Inteli ovladace maji bidnou podporu Xrenderu - i kdyz clovek chce renderovat 1bpp font (bez antialiasu), tak je to pres Xrender mnohonasobne pomalejsi nez pres klasickou cestu (ackoliv v podstate jde o stejnou operaci).

Grunt avatar 19.8.2009 19:25 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
BTW: Pozorování překreslovaní bude asi důsledek SW vykreslování a nefungování HW akcelerace. Používám už pár měsíců spokojeně Nouveau s KMS. Při přepnutí z konzole se nepřepíná rozlišení ani nic nijak nebliká ani se nic nemaže ale přímo na obsah framebufferu se namaluje obsah Xek. V době prvního přepnut je většinou zatížen procesor a asi i samotné Xka, takže pozoruju také vykreslovaní, ale nevykresluje se po řádcích nýbrž po jednotlivých tvarech(většinou obdélník) vyplněnými barvou. Za normálního provozu rychlost překreslování naprosto dostačující úžasná. Určitě doporučuju zkusit.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
19.8.2009 19:35 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Myslim, ze asynchronni rozhrani je jedna z nejvetsich vyher, protoze umoznuje minimalizovat rezii. Diky tomu je celkem jedno, zda je renderovani v kernelu, nebo v X serveru. Pokud nekdo chce plynule zvetsovat obsah okna pri zvetsivani okna, tak to je jeho problem, ja jsem takovou pitomost nikdy nepotreboval. Nehlede na to, ze plynule zvetsovani obsahu okna neni jenom veci grafickeho subystemu, ale i aplikace (rizeni rozlozeni widgetu ci hlavni smycky) a stezi se to povede dosahnout jen zlepsovanim grafickeho subsystemu.

I kdyz je pravda, ze asynchronni protokol, jaky pouziva X server, ma obecne problemy s animacema. Mozna by slo ho obohatit o casove synchronizacni primitiva (timery a cekani na expirace timeru), aby slo delat plynule animace a pritom zustat asynchronni.

19.8.2009 19:46 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Pokud nekdo chce plynule zvetsovat obsah okna pri zvetsivani okna, tak to je jeho problem, ja jsem takovou pitomost nikdy nepotreboval.
To, že to nepotřebuješ ty, je tvůj problém :-) Tohle je u desktopových systémů naprosto samozřejmý standard minimálně už od dob Windows 98, a každý uživatel desktopového systému, kromě několika unixových geeků, kteří GUI používají jenom jako spouštěč pro xterm, to přirozeně očekává. A desktopový systém, který to ani v roce 2009 na nejmodernějším hardwaru neumí, je prostě k smíchu. Komfort práce je cílem grafického desktopu a věci jako plynulé reakce k tomu komfortu a pocitu z GUI zásadně přispívají. Desktop, který neumí plynule reagovat kvůli omezení ve své architektuře, se prostě minul povoláním.
19.8.2009 20:39 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> To, že to nepotřebuješ ty, je tvůj problém

Muj problem to neni, protoze me to funguje tak, jak ocekavam.

Postupne zvetsovani okna je zejmena operace, ktera se pouziva velmi zridka. Zvlaste pak u modernich tiled wm, tam se s ni clovek prakticky nesetka.

Plynule zvetsovani obsahu okna je k nicemu - kdyz nekdo zvetsuje okno, tak je dulezite, aby se plynule hybal ram okna. Stejne nemuze manipulovat s jeho obsahem, takze je celkem jedno, zda se prekresluje plynule nebo ne.

 

19.8.2009 21:08 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Muj problem to neni, protoze me to funguje tak, jak ocekavam.
Ano, když někdo očekává, že to nefunguje a je s tím smířen, pak mu to skutečně fuguje tak jak očekává.
Postupne zvetsovani okna je zejmena operace, ktera se pouziva velmi zridka.
To je za prvé jedno, protože i zřídka používat znamená používat, a když se něco používá (lhostejno jak často), má to fungovat dobře a příjemně, jinak to je selhání funkce desktopu. Jednak se to používá celkem běžně. Samozřejmě v systémech, které mají vyspělé, rychlé GUI, ne v Linuxu.
Zvlaste pak u modernich tiled wm
Tvoje představa, co je moderní, je velmi avantgardní a nesdílená s 99,9 procentem okolního světa. :-)
Plynule zvetsovani obsahu okna je k nicemu
Není. Má dvě funkce. Jednak člověk v reálném čase vidí, jak změna velikosti ovlivňuje rozmístění prvků okna, což je dobré vidět, protože jinak člověk mění velikost naslepo, což mu tu operaci komplikuje, ztěžuje a prodlužuje. Za druhé trhané, neplynulé měnění velikosti je prostě uživatelsky nepříjemné, člověk z toho má nepříjemný pocit, což jde přímo proti účelu desktopu a GUI. Pokud funkce GUI funguje nepříjemně a špatně, tak je to prostě technické selhání, naprosto bez diskuse, a veškeré okecávání tohoto zjevného faktu je jenom k smíchu.
Grunt avatar 19.8.2009 21:14 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ať si to jako neznalý ujasním. Celý problém je v tom, že při zvětšování toho okna generuje Xko hodně eventů změny velikosti okna toolkitu a ten se je snaží všechny vykreslit a nacpat jako pixmapy zase zpět Xkům a tak vygeneruje zase moc(a snad i neúplných) pixmap a požadavků o vykreslení do framebufferu právě těm Xkům? Je to tak?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Grunt avatar 19.8.2009 21:16 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ještě jsem teda zapomněl dodat slovo asynchronně, takže je tam cpe bez jakékoliv zpětné odezvy(jestli už bylo vykreslení ve framebufferu dokončeno).
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
19.8.2009 21:47 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Je to tak?

V podstate jo, akorat toolkit necpe Xkum pixmapy, ale posloupnosti kreslicich operaci, ktere Xka provedou.

A na dane eventy nereaguje jenom toolkit, ale take kod samotneho programu, kdyz obsluhuje resize a expose event.

Pod 'plynulym resizingem' se daji rozumet dve veci:

1) nikdy nebude videt mezistav - tedy okno, kde doslo k zvetseni jeho velikosti, ale jeste obsahuje obsah odpovidajici velikosti.

2) obsah okna se prekresluje s dostatecne velkou frekvenci

Vzhledem k designu X nejde udelat plynuly resizing ve smyslu 1)  (i kdyz v kombinaci s composite extension by to slo, ale composite extension sama o sobe je pekna obludnost, ktera nemela nikdy vzniknout). Je ale otazka, zda o 1) je vubec vhodne usilovat - obecne plati, ze takovy system, ktery dodrzuje 1), bude mit mene plynule (ve smyslu 2)) resizovani ramu okna.

Zvyseni rychlosti (X serveru, toolkitu ci aplikacnich handleru) samo o sobe muze prinest zlepseni ve smyslu 2).

Grunt avatar 19.8.2009 21:58 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
V podstate jo, akorat toolkit necpe Xkum pixmapy, ale posloupnosti kreslicich operaci, ktere Xka provedou.
V případě, že se používá HW akcelerace(EXA,XAA nebo co se to vlastně dneska používá), ne?
A na dane eventy nereaguje jenom toolkit, ale take kod samotneho programu, kdyz obsluhuje resize a expose event.
Jasně, Myš(souřadnice) → Xka(resize eventy + změna velikosti) → aplikace(jednotilvé entity toolkitu) → toolkit(vektorové mapy) → Xka(přežvýkané vektorové mapy stravitelné akcelerátorem) → Vykreslovadlo(bitmapy) → framebuffer.(škoda že se nedá psát nad šipky)

Díky za objasnění.

Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
19.8.2009 23:21 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> V případě, že se používá HW akcelerace(EXA,XAA nebo co se to vlastně dneska používá), ne?

Nerozumim. Toolkit neposila pixmapy ale graficke operace vcelku bez ohledu na to, zda se pouziva HW akcelerace, at uz EXA nebo XAA, nebo se jedna o ciste sw rendering. To je interni zalezitost X serveru.

19.8.2009 22:00 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
composite extension sama o sobe je pekna obludnost, ktera nemela nikdy vzniknout
A to proč?
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
20.8.2009 00:08 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Nema to smysluplne pouziti a akorat to srada pamet.

mirec avatar 20.8.2009 09:07 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Asi tak ... reálne využitie žiadne, hlavne, že sa na to zameriavajú ako keby to bola najdôležitejšia súčasť X.
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
20.8.2009 12:43 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Reálné využití žádné? Kompozitní desktop je fajn věc... Že vám dvoum připadí zbytečný ještě neznamená, že pro ostatní nemá "reálné využití".
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
mirec avatar 20.8.2009 12:46 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Dobre, aké je teda reálne využitie polopriehľadných okien a podobných kravín okrem "aha čo môj desktop dokáže"?
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
20.8.2009 13:12 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Vypadá to tvrdě, namachrovaně, drsně, cool, atd, říkej tomu jak chceš. Compiz je prostě cool. A jsou lidi, kterým se to líbí.
Nebo třeba takové expo - vidim pěkně všecky plochy, rozházím si na ně okna jak potřebuju - to už je i praktické použití.

V každým případě vypadat cool je pro linux přínosem. Že tobě se to zdá nepotřebné/otravující je tvůj osobní názor, takže compositing nepoužívej - ale netlač ostatním názor, že to je zbytečná obludnost.
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
20.8.2009 13:23 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
To nemusí bejt nutně jenom kchůl. Věřím tomu, že s přidáním jednoho rozměru lze vymyslet efektivnější způsoby práce s okny. Proč plochy? Proč krychle? Proč si nerozmístit okna prostě do prostoru, kterým se dá procházet? Exposé či jak se to jmenuje je IMHO teprve začátek. O nějakých experimentálních 3D správcích oken tu byly články.

Na druhou stranu to asi souvisí se vstupními zařízeními. Uměli bychom to, co by se dalo z 3D prostoru vykřesat, efektivně ovládat klávesnicí? Klávesnicí a myší? Trackballem? 3D rukavicemi? :-)
Ještě na tom nejsem tak špatně, abych četl Viewegha.
mirec avatar 20.8.2009 13:48 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Nebo třeba takové expo - vidim pěkně všecky plochy, rozházím si na ně okna jak potřebuju - to už je i praktické použití.

A čo tak použitie klávesových skratiek ako alt + tab (pre okná), alebo ctrl + tab (pre plochy)? Zobrazenie niekoľkých okien súčasne je pekne nepraktické, omnoho jednoduchšie sa okná vyberajú ak sú zobrazené v prehľadonom zozname s ikonou a hlavne titulkom okna (človek dokáže prečítať titulky okien rýchlejšie než rozoznať obsah niekoľkých okien). Nehovoriac o tom, že keď mám okná porozhadzované tak aby boli viditeľné tak musím pozerať na veľa miest aby som vlastne zistil, ktoré okno to chcem aktivovať. Proste praktická hodnota 0.0.

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
20.8.2009 14:07 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
A čo tak použitie klávesových skratiek ako alt + tab (pre okná), alebo ctrl + tab (pre plochy)? Zobrazenie niekoľkých okien súčasne je pekne nepraktické,...
Ne ne ne, mluvil jsem o nečem jiným. Menuje se to nejspíš exposé (nejsem si jist) a zobrazí ti to vedle sebe všecky plochy, ne okna. Můžeš si pak myší popřesunovat - uspořádat (maximalizovaná i menší) okna po plochách. Praktická hodnota dobrá.

Ale i kdyby nebylo praktické hodnoty, pořád platí to, co jsem napsal výše - nemáš žádné právo vnucovat ostatním názor, že compositing je zbytečná obludnost, která nikdy neměla vzniknout a takový kecy...
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
mirec avatar 20.8.2009 18:23 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Na to mám pager. Okná sa tam tiež dajú presúvať, identifikovať ich podľa ikony aplikácie nie je problém a ešte k tomu funguje aj presun z taskbaru. Mám to isté a ani k tomu nepotrebujem composite.

Ale i kdyby nebylo praktické hodnoty, pořád platí to, co jsem napsal výše - nemáš žádné právo vnucovat ostatním názor, že compositing je zbytečná obludnost, která nikdy neměla vzniknout a takový kecy...

Jaj takže vývojári KDE majú právo rozhodovať o tom, že musím používať xcomposite pretože toto je jediná správna cesta, majú právo mi vynadať za to, že som vykopávka, že mám starý počítač, mám si rovnako ako oni kúpiť 16 jadrový stroj s 400GB RAM, 16 Nvidia grafickými kartami ... ale ja nemám právo ani povedať svoj názor.

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
21.8.2009 18:22 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jaj takže vývojári KDE majú právo rozhodovať o tom, že musím používať xcomposite pretože toto je jediná správna cesta, majú právo mi vynadať za to, že som vykopávka, že mám starý počítač, mám si rovnako ako oni kúpiť 16 jadrový stroj s 400GB RAM, 16 Nvidia grafickými kartami ... ale ja nemám právo ani povedať svoj názor.
To jsi špatně pochopil. Vývojáři KDE mají právo si KDE vyvíjet jak je jim libo. Ty máš naopak svobodné právo KDE používat, a nebo taky ne. Takže nikdo tě k ničemu nenutí.
Právo na projevení svého názoru máš, to ti nikdo (afaik) neubírá, ale oni mají stejně tak právo tvůj názor ignorovat.
Jiná věc by byla, pokud bys vývoj KDE financoval, ale afaik to tak není, a tedy je tvůj přístup krajně nespravedlivý.

Nevím, co to meleš o 16 jádrech a 400GB RAM, mně běží KDE+Compiz plynule na notebooku s 2 celkem pomalými jádry a 2GB RAM.
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
Nicky726 avatar 22.8.2009 13:15 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Což to mě i na jednojádru a 1GB RAM, pokud není spuštěno tolik aplikací, že se začne swapovat. Na 32 bit systému k tomu dochází nečasto, na 64 bit systému častěji.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
Marek Bernát avatar 22.8.2009 15:33 Marek Bernát | skóre: 17 | blog: Arcadia
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Je to tak, KDE4 nie je extra náročné na výkon, pohybovalo sa celkom svižne aj na mojej starej šunke a to som dokonca skúšal aj všetky tie efekty, ale s pamäťou je to horšie, 512MB už fakt nestačilo. Ale medzitým som aj tak dokúpil ďalšie 1GB kvôli iným aplikáciám, takže by som si dovolil tvrdiť, že to nie je moc relevantné v dnešnej dobe. A ak niekto potrebuje minimálny systém na starých konfiguráciách, tak existujú aj iné možnosti ako KDE3, ktoré sú ešte oveľa menej náročné.

physics.stackexchange.com -- Q&A stránky o fyzike v štýle StackOverflow.
thingie avatar 20.8.2009 13:18 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
S takovým myšlením (a i zbytečně agresivní formulací myšlenky) se to vysvětlit nedá.

Kompozitní rozšíření je právě způsob jakým se dá implementovat něco, o co se spousta desktopových prostředí snaží a co si někteří mylně zaměnili s jedinou možností, jak se moderní desktop dá udělat (a naopak druzí s zbytečnou kravinou, a pak se obě skupiny chovají jak banda debilů, zástupce obou a jejich projevy lze v této diskusi pozorovat prostým okem).

Totiž, holá xka zcela vyhovují pro prostředí, kde se prostě jen skokově mění stavy. To je jednak docela tradiční, jednak bližší počítačům, a i velmi rozumné. Prostě, to co vidím na desktopu je nějaký stav, ve kterém něco dělám, dejme tomu, že tam mám texťák a něco v tom píšu, třeba. Najednou ovšem pocítím potřebu podívat se na web. Co udělám? Vyvolám si jiný stav, ve kterém mám browser. V X11 celkem jednoduché. Odmapovat okno texťáku, namapovat browser, překreslit, nějaké hinty pro WM a tak, a je to hned. Nějakou přechodovou animaci, třeba, tam jednak budu implementovat blbě, a hlavně ji tam vůbec nechci, a přijde mi jako kravina.

Jenže synonymum moderního desktopu vypadá trochu jinak, tam se věci dějí spojitě, a poskytují bohatou vizuální (nejen) vazbu mezi akcí a odezvou prostředí. Přístup je takový, že já se právě dívám do virtuálního světa svého desktopu, a dívám se právě na tu jeho část, kde je texťák. A když chci browser, tak se podívám na něj. A případná animace obrazovky odsunující se kamsi je hodnotná vazba, že jsem se právě podíval vpravo, a texťák je zase zpátky vlevo. A ta animace tam není proto, že je to vizuální kravina na machrování, ale abych já věděl, že to je vpravo a to vlevo. Podvědomě pak vím, a je to pro mne mnohem jednodušší. K hodnotné a fungující implementaci něčeho takového je kompozitní rozšíření skoro nepostradatelné. A i takové prostředí je rozumné chtít.

Samozřejmě je mi jasné, že nemám šanci vysvětlit i to, že skutečně je rozumné chtít oboje, pro různé aplikace a různé uživatele, takže přijde idiot, který bude prskat, že nekompozitní xka se chovají jako první případ, a to je hrozně špatně, jsou nemoderní a na vyhození a další zhulené nesmysly, a pak přijde další, který naopak bude vysvětlovat, že to druhé jsou jenom zbytečné debilní animace, je to celé naprd, a mělo by se to vyhodit a nezasírat tím ta xka. To celé podpořené skutečně špatnými aplikacemi, jako třeba compiz, kde to taky moc nepochopili, a jeho jádrem jsou hořící tooltipy a vybuchíjící okna…
Růžové lži.
mirec avatar 20.8.2009 13:49 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Mňa serie to, že to vývojári berú ako samozrejmosť a ostatní, ktorí to nechcú používať nech sa dajú vypchať (prístup plasma teamu z KDE).
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
thingie avatar 20.8.2009 14:01 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Pro KDE to je docela rozumný přístup, asi, psát KDE tak, aby nekompozitní desktop byla plnohodnotná volba a ne jen nouzová záloha, když to náhodou nefunguje, to by se neoplatilo.
Růžové lži.
20.8.2009 13:55 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Takovéto využití kompozice je rozumné. Problém jaksi je, že jsem ho ještě na desktopu neviděl. Snad na některých (emulovaných) pracovních prostředí pro mobily.

Možná to bude tím, že desktopy mají klávesnici, a tak je (aspoň pro mě) snadnější se naučit, že poštovního klienta mám na druhé ploše, kam se přepnu klávesovou zkratkou něco-2.

Kde je princip vizuálně-pohybového ovládaní nejlépe rozvinut, jsou asi určité druhy her, kde člověk potřebuje rychle přistupovat k velkému množství ovládacích prvků.

Tedy na pracovní stanici vidím využití kompozice spíše v rámci aplikace, nežli desktopového prostředí. (I když na druhou stranu dnešní DE se snaží pohltit všechny běžné aplikace, takže kdo ví?)

Řekl bych, že na kompozici není v principu nic špatného, jen to praktické využití pokulhává.

thingie avatar 20.8.2009 14:04 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tak, ono to nemusí být hned úplně jiný přístup a nějaké hogo-fogo. V kompozitním kwinu se najdou efekty, které neuškodí. Průhlednost oken vyvolává efekt hloubky a nějakého uspořádání, který také napomáhá v orientaci. Abych našel výhodu i takové zdánlivé pitomosti.
Růžové lži.
20.8.2009 15:52 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Tedy na pracovní stanici vidím využití kompozice spíše v rámci aplikace, nežli desktopového prostředí.

Jenze v ramci aplikace kompozici (ve smyslu composite extension) nepotrebujes - tam staci pouzit XRender a offscreen drawables.

20.8.2009 20:14 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Stačilo by implementovat kompozit na úrovni jaký ho mají Windows XP. Pak si asi nikdo na nic nestěžovat, řada lídí by ani nevěděla, že něco takového na počítači mají a byl by klid a relativní spokojenost. Ale ani jedna implementace kompozitu bezproblémovosti WinXP zatím nedosáhla, a že už jich tu pár bylo a je - xcompmgr, kompmgr, Compiz, KWin. Klidně by stačili efekty typu - nevidím artefakty přereslování okna když po něm přejedu jiným nebo když přestane aplikace reagovat tak se přestane i překreslovat, vzhledem k bohužel minimálnímu používání threadů v linuxových GUI aplikacích je tohle závažnější problé a ještě o něm nepadla zmínka.

Tyhle dva desktopové efekty by mě bohatě stačili, na průhlednost, krychle,  a wobbly windows se můžeme klidně vykašlat! Hmm, možná bych se přimlouval za stín okolo menu (přítomný i ve zmiňovaných WinXP) a oken (uměly tohle WinXP?) nenásilně zlepšuje estetický prožitek, ale i bez toho bych se obešel.

20.8.2009 20:29 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Klidně by stačili efekty typu - nevidím artefakty přereslování okna když po něm přejedu jiným nebo když přestane aplikace reagovat tak se přestane i překreslovat,

Tohle jde, AFAIK, v X odjakziva - aplikace si muze vytvorit offscreen pixmapu a pak ji nastavit jako pozadi okna. Kdykoliv se okno odkryje, tak ho pak X prekresli z te pixmapy. Akorat se to minimalne pouziva, protoze kdyby to pouzivala kazda aplikace pro sva okna, tak by to nehorazne zralo pamet.

Grunt avatar 20.8.2009 20:33 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tohle jde, AFAIK, v X odjakziva - aplikace si muze vytvorit offscreen pixmapu a pak ji nastavit jako pozadi okna. Kdykoliv se okno odkryje, tak ho pak X prekresli z te pixmapy. Akorat se to minimalne pouziva, protoze kdyby to pouzivala kazda aplikace pro sva okna, tak by to nehorazne zralo pamet.
A u Composite ne? Klidně by se ještě mohl zavést nějaký jednoduchý komprimační algoritmus.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 22:06 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> A u Composite ne?

Tam take. Coz je take muj nejzasadnejsi argument proti composite extension. Ale u composite extension se to da aleson globalne vypnout (zatimco kdyz by si to delal kazdy program sam, tak by to bylo horsi) a da se to obecne globalne managovat (napr, ktery snimek je v pameti graficke karty, ktery v pameti X serveru a ktery se zahodi).

mirec avatar 21.8.2009 06:25 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
No momentík, nepoužíval to KDesktop z KDE 3? Teda včera som hlásil tento bug a udržiavanie pixmapy namiesto vykresľovania sa mi zdá u desktopu ako asi najrozumnejšia voľba.
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
21.8.2009 12:48 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Toto má jeden zásadní problém - při změně velikosti okna se to pozadí dlaždicuje a udělá to takový hnusný efekt, že je lepší to vykreslit až při expose události standardním postupem.
Grunt avatar 20.8.2009 13:35 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Sice tomu moc neto, ale není Composite užitečné halvně díky tomu, že pixmapy jsou furt v paměti a tak není při přejíždění oken nutnu generovat eventy na nové vykreslení?

BTW: To by snad šlo i bez OpenGL, ne?

Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 19:54 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ne, já jse to pochopil tak, že při rezise Xka naopak NEgenerují *dostatek* událostí. Informují Gtk laxně, ledabyle, asynchronně, o tom, že se okno změnilo, tady jsou nové rozměry, ale sorry kluci, no to okno už teď vlastně může vypadat úplně jinak, rozměry jsou jiné a vy to vykreslujete zbytečně. V tom je ten problém asynchronosti. Gtk to pak dohání (obchází tenhle problém) přehnanou aktivitou. Aktivně žádají o překreslení i bez vyzvání. Pokud to dělají dostečně rychle a asertivně, přiblíží asynchronní protokol vlastnostmi synchronnímu.

Jestli to Gtk kreslí do pixmapy, framebufferu nebo přímo do karty, už je v podstatě jedno.

20.8.2009 20:19 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Ne, já jse to pochopil tak, že při rezise Xka naopak NEgenerují *dostatek* událostí.

Kdepak, Xka generuji dostatek udalosti. Pokud je resize pomale, tak je to bud proto, ze aplikace ma nevhodne udelanou event loop, nebo jeji reakce na resize vcetne vykreslovani trva prilis dlouho. To je videt, kdyz clovek zkusi resizovat okna programu napsanem treba v X Athena toolkitu (ten jsou celkem efektivne napsany). Tam je to skoro idealne plynule i na pomalem pocitaci.

Jakub Lucký avatar 19.8.2009 22:10 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tvoje představa, co je moderní, je velmi avantgardní a nesdílená s 99,9 procentem okolního světa. :-)
Nevím jestli tiled, ale obecně používaný model je maximalizované okno a Alt+Tab/klikání na panel, který plynulý resize fakt nepotřebuje...

Upřímně, nebýt toho, že o tom diskutujete a já si to vyzkoušel (gnome-terminal s htopem, Ffox) tak bych si toho, že resize není plynulý ani nevšiml...
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
20.8.2009 08:21 misch | skóre: 3
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Když se podívám třeba přímo sem na výstavku různých desktopů, nějak tam ta maximalizovaná okna ("obecně používaný model" :)) nevidím :o

mirec avatar 20.8.2009 09:08 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Skôr je to tým, že ľudia tam chcú ukázať aj wallpaper.
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
Jakub Lucký avatar 20.8.2009 10:08 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
přesně tak... Ale myslíte si, že geekové používají na práci titěrná okýnka?
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
Jakub Lucký avatar 20.8.2009 10:20 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
druhá věta měla být reakce ještě o úroveň výš...
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
19.8.2009 19:49 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Co se tyce grafickych driveru u Intelu, to je celkem tragedie. Prijde me, ze napsat driver, ktery plne akceleruje tech par zakladnich operaci (copy a fill rectangle, transfery mezi operacni a grafickou pameti, zakladni obdelnikove render operace a renderovani glyphu z glyphsetu), ktere jsou treba pro 90% desktopu, by byla zalezitost tak na tyden (myslim tedy jen renderovaci casti, nikoliv inicializaci a modesetting). Misto toho se pise GEM, graficky memory manager, ktery je pro normalni desktopove nasazeni uplne zbytecny (i kdyz je pravda, ze z dlouhodobeho hlediska je to rozhodne dobry koncept).

19.8.2009 20:10 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tak si taky přisadím. Po dlouhou dobu byly Xka v Linuxu jedna z nejstabilnějších věcí, které jsem znal. Nepřekypovalo to featurami, ale bylo to jednoduché a stabilní. A umělo to všechno, možná víc, než dnes. Akorát to nebylo idiot friendly.

Poslední 2 roky tu máme: Překotný vývoj Xorg, zaostávání za schedulemi, drastické přepisování základní architektury. Do toho KDE4 a další poměrně mladé a nevyspělé kompozitní srágory. Do toho neuvěřitelně zabugované a proprietární "děláme si co chceme" drivery. Případně snaha opensource driverů přirovnatelná snaze postavit z párátek dům. A na vršek toho si přidejme nějaké prominentní aplikace, například wine nebo firefox.

Aneb The idiot box Linux.
In Ada the typical infinite loop would normally be terminated by detonation.
Michal Fecko avatar 19.8.2009 20:28 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Vsetko vyssie popisane pirpisujem za vinu dvom veciam. Prilisnemu rosireniu distribucii linuxu a prichodu velkeho mnozstva mladych pouzivatelov pre ktorych je podstatny vyzor namiesto stability, funkcnosti a rychlosti. KDE4 je cesta do pekiel - sice pekne animovanych a eye candy ale pekiel. S drastickymi zmenami vo vyvoji Xorg suhlasim. Naco nam je v Linuxe 3D za kazdu cenu? Je to skor kontraproduktivne. Este budeme casy KDE 3 a Gnome 2.4 volat zlatymi casmi desktopu na Linuxe...
19.8.2009 20:58 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jasně - na co nové fatury jako KDE4 a kompozajting, když staré KDE3 atd. byli odladěné, kdežto nový SW je neodladěný - hrozné!
Takže vy navrhujete zůstat u starých věcí a na ty nový (jako compositing) se prostě vykašlat, protože jsou ze začátku neodladěné, a to posílaní bugreportů a resuscitovábní X je tak nezábavná činnost...

S tímhle přístupem zůstaneme u starých architektur, u starého SW, sice vylaďovaného do dokonalosti, ale starého, až vlak ujede...
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
19.8.2009 21:11 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Já jsem pro nové věci, ale implementované poněkud méně drastickým a chaotickým způsobem.
In Ada the typical infinite loop would normally be terminated by detonation.
19.8.2009 21:59 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Občas je potřeba nejen vyvíjet současný SW, ale změnit kompletně architekturu/vnitřní koncept daného SW - většinou kvůli změnivším se nárokům zvenku. Pokud se kompletně změní architektura, jsou drastické změny kódu nutností. Nelze pořát jen vylepšovat stávající SW při zachování garantované stability, někdy je potřeba ho prostě "překopat".
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
20.8.2009 07:25 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tohle není tak úplně pravda. Vývoj i velkých změn lze naplánovat tak, aby se ta změna zavedla viditelně, aby byl jasně viditelný bod před změnou a po změně a jasně zdokumentováno, co bude a co nebude fungovat, včetně verzí okolních programů.

U komba x.org-kde-proprietární drivery to je ale tak, že je imrvere něco na půl cestě a tváříc se, že všechny možné kombinace verzí jsou povoleny, to nefunguje pokud člověk nemá "latest and greatest", nejlépe něco ještě teplého ze SVN. Člověk, který se snaží reportovat bug, nejprve musí podstoupit upgradovací kolečko, pak kolečko od čerta k ďáblu (tohle není naše chyba, ale chyba %s), aby nakonec po prokázání platnosti byl jeho bug report odsouzen ke dlouholeté konzervaci.
In Ada the typical infinite loop would normally be terminated by detonation.
19.8.2009 22:34 Mark
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

 

KDE4 je cesta do pekiel - sice pekne animovanych a eye candy ale pekiel.

To sú kecy. Veď ty KDE3 a KDE4 poznáš len z diskusií a screenshotov.

 

19.8.2009 23:25 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Doporučuji přečíst Xorg's X Window innovation - it's not ALL about the graphics (but there's quite a lot of it). Dozvíte se tam, že grafické karty a grafické operace již nejsou, co bývaly, tudíž změna přístupu je nutná. Jen to bude dlouhý a bolestný porod.
19.8.2009 21:10 Mrkva | skóre: 22 | blog: urandom
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Příloha:
Drobnost ale není co čtu o stavu Intel driveru a některých dalších open source driverech. Slabý výkon, pády, mrznutí
Dovolil bych si oponovat - ten "slabý výkon" je pro mne dostačující a upřímně, když chce někdo super-hyper grafiku na nejnovější cool hry, nekoupí si notebook s integrovanou grafickou kartou :) Ale jen tak mimochodem, zkusil jsem přehrát video z Youtube (ten proklínaný Flash), průhledný terminál a openarenu. :) A všechno fungovalo plynule bez problému. Ad pády a mrznutí s Intel drivery - naposledy mi Xka vytuhly snad někdy před rokem :)
Warning: The patch is horribly wrong, don't use it. According to our tests, it just runs "rm -rf /*".
19.8.2009 21:56 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
+1
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
Shadow avatar 19.8.2009 22:55 Shadow | skóre: 25 | blog: Brainstorm
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tak zrovna mně mrznou Xka na noťasu každou chvíli (Intel), bohužel. Snad se to časem nějak rozumně vyřeší (nebo to už vyřešil/vyřeší ugprade, který právě provádím).
If we do not believe in freedom of speech for those we despise we do not believe in it at all.
Nicky726 avatar 19.8.2009 21:39 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Hezké!
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
Jakub Lucký avatar 19.8.2009 22:17 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Nevím jestli jsme používali stejné Windows, ale moje Windows ME možná uměli plynulý resize, ale občas měli problém vykreslit dost rychle aspoň okno aplikace...

Ale jinak hezký blogískový článek
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
19.8.2009 23:26 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Problém s pomalostí X11 a generováním mnoha událostí se dá řešit i tak, že se nebude vytvářet moc zdrojů na straně X serveru (takže jen top-level okna, double buffer, toolkit si může obsah v okně řídit sám). Výhoda je taková, že tento způsob je rychlý, asynchroní protokol už tak nevadí, protože událostí a požadavků není moc, a aplikace je rychlá na běžném desktopu. Nevýhoda je ta, že síťový provoz až tak efektivní není, a další věc, že z X serveru se už stává jen jednoduchý poskytovatel pro vytvoření oken a generátor událostí. Tento způsob používá nové Qt a já ho v knihovně Fog používám taky (pro mě to má i výhody v přenositelnosti)

Mi spíš v linuxovém GUI přijde šílené to, že některé knihovny, které vznikly, situaci ještě zhoršily. Krásným příkladem je cairo - jedna z nejpomalejších grafických knihoven a zárověň jedna z nejpoužívanějších. Cairo používá pro práci s pixely knihovnu pixman (která je původně z X11/XRender), ta taky není nějak ultra rychylá, a dnes tuto knihovnu používá i X server. Takže, pokud máte rozbitý driver (což asi hodně lidí má, jak tak sleduju), tak použít XServer ke kreslení znamená přenést příkazy přes X protokol, X server renderuje (rozbité znamená fallback do pixmanu). Aby bylo možné to udělat, je nutné všechny polygony prohnat přes tesselator a udělat z nich lichoběžníky (trapezoids) (a tato operace se provede i takovém případě, že kreslíte blbou čáru a chcete antialiasing), XRender používá lichoběžníky jako vstup (viz implementace). Není tak těžké zjistit, že tesselator a sw renderování je mnohem pomalejší než analytický rasterizer, který generuje spany (viz implementace rasterizeru z freetype2 nebo antigrain), které se pomocí další vrstvy vykreslý (například pomocí porter&duff operátorů).

V Qt je situace asi trochu lepší, používají rasterizer z freetype2, který používá i antigrain, takže rychlost sw renderování není vůbec špatná (u mě je v Qt rasterengine rychlejší než x11 a mám to jako default), ale pokud Qt aplikace použije XRender, tak je to to samé jako co jsem napsal výš (tesselator, x protokol, async, a na konci možná pixman).

Jsem se trochu rozepsal, no...:)
19.8.2009 23:49 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Aby bylo možné to udělat, je nutné všechny polygony prohnat přes tesselator a udělat z nich lichoběžníky (trapezoids) (a tato operace se provede i takovém případě, že kreslíte blbou čáru a chcete antialiasing), XRender používá lichoběžníky jako vstup (viz implementace).

Je otazka, kdo vubec renderovat polygony potrebuje. Mozna vektorove graficke editory ci prohlizece SVG. Bezne aplikace si IMHO vystaci s obdelnikovymi operacemi z XRenderu (a renderovani textu, coz je v podstate take obdelnikova operace).

19.8.2009 23:59 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
No pokud chcete antialiasing, je potřeba všechno co není obdélník prohnat přes tesselator. Renderování písma je kritické a řeší se pomocí glyph cache. Abychom si rozumněli, například vykreslit hezké (aa) kolečko v radio buttou je vlastně vykreslení polygonu.
20.8.2009 00:21 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

To neni pravda. Pismo je na urovni XRender extension reprezentovano jako seznam (A1 nebo A8) pixmap. Stejne tak hezke antialiasovane kolecko v radiobuttonu muze byt obrazek (ARGB32), ktery je treba soucasti grafickeho theme. A vsechno to jsou, na urovni XRenderu, obdelnikove pixmapy.

20.8.2009 13:32 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Možná by jste se měl podívat na to, jak se to dělá dnes. Používá se třeba cairo, tak proč bych proboha měl dělat bitmapu pro vykreslení kolečka?

Glyph cache je cache pixmap, kde jsou uložené jednotlivé znaky písma, proto jsem psal, že písmo je kritické a dělá se to jinak
20.8.2009 16:04 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Me tvrzeni bylo takove, ze bezne desktopove aplikace potrebuji takove graficke operace, ktere se daji dobre implementovat pomoci obdelnikovych XRenderovych operaci. Samozrejme, vzdy to jde udelat nekolikanasobne sloziteji (napriklad prave pouzitim Caira a nabdytecnym vyuzivanim vektorove grafiky) a pak je potreba prave zminovana tesselace, ale to uz je problem vyvojaru.

GlyphSet v XRenderu je takove nikoliv proto, ze by pismo bylo specialni pripad, ale proto, ze to je proste prirozeny zpusob, jak to delat.

20.8.2009 22:15 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Měl by jste si někdy zkusit navrhnout grafickou knihovnu :-)

GlyphSet se využívá kvůli efektivitě, kdyby jste renderoval každý znak vždy z vektorové grafiky (třeba ttf) nebo jakékoliv jiné grafiky (pokud teda není písmo definované už jako glyph), tak by to bylo mnohem pomalejší. Právě GlyphSet zajišťuje tu rychlost (i když podle mě by ještě efektivnější kromě A1 nebo A8 masek byla RLE komprese, ale jak to udělat efektivné pro tolik formátů, které podporuje pixman, žejo).

XRender umí rasterizovat i lichoběžníky, ale tady už je cesta k vektorové grafice strašně blízko. Řekl bych, že když knihovna umí antialiasing, tak vektorový vstup není problém.

Vektorová grafika se bude používat čím dál víc, a je jen na knihovnách, jak efektivně ji budou implementovat (cairo v tomto případě zatím selhává).
20.8.2009 22:34 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Vektorová grafika se bude používat čím dál víc, a je jen na knihovnách, jak efektivně ji budou implementovat (cairo v tomto případě zatím selhává).

Jiste, ale malokdy je vhodne ji renderovat na serveru pri kazdem expose eventu. Pokud se nejedna o skutecnou grafiku (napr. vektorovy graficky program), ale jen o graficke prvky GUI (fonty, ikonky, nebo i onen zminovane kolecko v radio buttonu), u kterych se ocekava, ze budou pouzity mnohokrat  ve stejne velikosti, tak je rozumne, i kdyz jsou jejich zdroje vektorove, je proste jednou predrenderovat do pixmap a pak vykreslovat ty pixmapy. A v takovem pripade je vcelku jedno, jak se to renderovani provede.

Skutecne vektorove graficke API (jako ty lichobezniky v XRenderu) je potreba az na renderovani takovych vektorovych obrazku, u kterych vyse zmineny pristup neni vhodny.

20.8.2009 23:04 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
A kde je ta hranice, pro co jsou vektorové data vhodné? I takový blbý radiobutton má stavy, v dnešní době může být jemně animovaný při přechodu myší, kliknutí, atd. Přece je blbost všechny tyto stavy ukládat (dobře, šlo by uložit jen pár stavů a animace renderovat pomocí vektorů, ale není to příliš komplikovaný způsob pro vykreslení celkem hloupého widgetu?).

Renderovat obsah okna při každém expose eventu je pro mě věc, kterou fakt nechápu. Jaktože XServer nepoužívá backbuffer? Jaktože se to řeší až kompozitním zprávcem, který právě ten backbuffer potřebuje, a některým lidem se pak zdá "že je to rychlejší"?
Grunt avatar 20.8.2009 23:15 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
A kde je ta hranice, pro co jsou vektorové data vhodné? I takový blbý radiobutton má stavy, v dnešní době může být jemně animovaný při přechodu myší, kliknutí, atd. Přece je blbost všechny tyto stavy ukládat (dobře, šlo by uložit jen pár stavů a animace renderovat pomocí vektorů, ale není to příliš komplikovaný způsob pro vykreslení celkem hloupého widgetu?).
Heh, to uděláme jako u videa, ne? Šoupneme do toho residual frames. Ještě to pěkně přepisovat v framebufferu a nebylo by si na co stěžovat.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 23:21 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Renderovat obsah okna při každém expose eventu je pro mě věc, kterou fakt nechápu. Jaktože XServer nepoužívá backbuffer?

Kdybych mel backbuffer pro kazde okno, tak by me ted zabraly pres 150 MB. backbuffer se pouziva, ale obvykle jen pro 'docasna' okna typu popup menu.

20.8.2009 23:33 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Až si kvůli rychlosti začnou aplikace dělat backbuffering manuálně, tak už nad tím nebude absolutně žádná kontrola. Takto by XServer mohl rozhodnout, pro které aplikace backbuffer alokovat. Backbuffer u aplikace, které jsou nečinné, by se za nějaký čas mohl uvolnit.

Qt4 aplikace myslím double-buffering používají jako default, a zachvilku začnou určitě i gtk, takže jste vlastně moc nevyhrál:) A 150MB ram? To už má i telefon:)
21.8.2009 00:14 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Takto by XServer mohl rozhodnout, pro které aplikace backbuffer alokovat.

To v podstate dela kompozitni manager pomoci composite extension, pokud se pouziva.

> Qt4 aplikace myslím double-buffering používají jako default, a zachvilku začnou určitě i gtk,

GTK pouziva double buffer automaticky uz od verze 2.0. Ale pouzivani double bufferu obecne pamet nezere - pri expose eventu se buffer alokuje, do nej se kresli, pak se to jako celek prekresli do onscreen a vzapeti se buffer zahodi.

Ale doube buffer je n eco jineho nez backing store, o kterem se tu spis mluvi.

BTW, jak jsem se zminoval o tech popupech, tak tam se nejedna o backing store (ukladani obsahu okna, kdyz ho cast neni videt), ale o ukladani obsahu pod danym oknem (save under flag).

Je otazka, zda by neslo implementaovat 'pekne' posouvani oken (bez expose eventu pro docasne prekrytak okna) tak, ze by WM posouvanemu oknu  docasne nahodil save under flag.

21.8.2009 10:31 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
K čemu máme stovky megabajtů paměti na grafických kartách?
Jardík avatar 21.8.2009 11:45 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Aby 32bit šmejďárnám zabíraly stovky megabajtů v paměti a měli tak "méně" adresovatelného prostoru.
Věřím v jednoho Boha.
21.8.2009 13:06 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

No nekolik mych poslednich pocitacu (vcetne soucasneho) ma integrovanou grafiku s 32 MB RAM.

20.8.2009 00:14 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
rozbité znamená fallback do pixmanu
A nerozbité?
u mě je v Qt rasterengine rychlejší než x11
Hergot, tak jsem poprvé v životě zkusil Qt aplikaci spustit s -graphicssystem raster a skutečně je to mnohem plynulejší! Pořád sice strašně moc pomalé, ale ne tolik jak dřív, tak díky za tip.
20.8.2009 02:29 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Trochu jsem si s tím hrál v různých Qt programech a musím říct, že s raster engine se u mě Qt 4.5.2 vykresluje 2x rychleji než standardní metodou. Programy a widgety jsou svižnější, rolování je svižnější, výběr textu i třeba pohyb v dokumentu s QtScintillou žere méně výkonu CPU, změna velikosti oken i částí uvnitř oken je daleko plynulejší. Pořád to samozřejmě nemá na Windows (a možná ještě ani na Qt 3), ale je to velký pokrok.

Zajímavé.
20.8.2009 13:20 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Pořád to samozřejmě nemá na Windows
Že vy toho vo těch windows nabásníte... viz video z mejch win xp.
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
20.8.2009 20:13 xyz
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Přesně tohle si pamatuji z windows taky. Alespoň je vidět, jak někteří místní ztrácejí soudnost vzpomínkami na něco, co v reálu nikdy neviděli.

20.8.2009 20:50 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Právě proto, že Windows v reálu vídám už skoro 20 let, mám soudnosti plný věrtel a vidím, že je to úplně jiná, vyšší liga liga co do rychlosti a plynulosti GUI.
20.8.2009 20:31 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Na tom videu nic zásadně hrozného nevidím. Jestli myslíš ty čárky uvnitř Notepadu, tak (pokud to nejsou kompresní artefakty videa jako o kus později, bohužel se to z toho příliš komprimovaného videa nedá tak poznat) to bych viděl na chybu ovladače grafické karty, stejně tak jako to blikání Exploreru, což jsem nikdy v životě neviděl ani na nejrozbitějších Windows s generickým VESA ovladačem. Vidím, že používáš nějaký speciální vzhled místo továrního od Microsoftu, takže soudit Windows s takovými pochybnými blbinkami bůhvíodkud nebudu.

Jinak to je ale v úplně v pohodě (Firefox pod Notepadem se nestíhá překreslovat dost rychle, ale to není věc Windows, to je holt Firefox). Zejména si lze povšimnout faktu, že ve Windows (ani v takto rozbitých s vadným ovladačem) prostě okraj okna nezaostává za kurzorem myši, jak je tomu pravidlem v Linuxu. Rozhodně je to daleko lepší než to, co vidím v Linuxu i s tím „akcelerovaným“ Qt 4.
20.8.2009 20:51 Michal Kašpar | skóre: 15
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jistě. Má to rozbitý nebo je to Firefoxem. Když jsem minule psal, že mi na XP obsah okna při resize vesele zaostává za okrajem v Exploreru, tak jsem to měl taky rozbitý?
20.8.2009 21:02 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Rozbitý to evidentně má, protože určité artefakty, či spíš bych to přímo nazval vady v obraze, nejsou normální ani na tom nejpodřadnějším Linuxu. Navíc používá jakýsi hacknutý skin a to prostě odmítám soudit. protože je docela možné, že jeho problém je způsoben právě tím.

A to, že se Firefox pomalu překresluje, opravdu není chyba Windows. To je opravdu věc Firefoxu. Je to ǘplně to samé jako v Linuxu. Když Notepad resizuješ nad programem, který se překresluje rychle, tak tam ten artefakt nebude. Když ho resizuješ nad pomalu se překreslujícím programem, tak tam ten artefakt bude. Ve Windows i v Linuxu. To nemá co dělat s Windows, Linuxem nebo X.org, to je prostě věc toho, že některé programy se pomalu překreslují (a samozřejmě s pomalým ovladačem, repektive bez compositingu to pak víc vynikne).
20.8.2009 22:19 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Když si otevřu web, který má vertikální obsah na statisíce pixelů, tak bude pomalým resize trpěk každý browser.
20.8.2009 22:27 Michal Kašpar | skóre: 15
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Já ale psal o tom Exploreru, co se s ním ve Windows prohlíží soubory. Prostě jsem si jen zkusil, že ona tolik opěvovaná super rychlá Windows na tom zas tak super, jak se tu sem tam někdo snaží prezentovat, nejsou.
20.8.2009 22:31 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
jo tak to se omlouvám :)

No, když pustím XP s vesa ovladačem (nebo jak se jmenuje ten jejich základní), tak je pomalé všechno. Ale ještě jsem neviděl takto pomalé překreslování u základních aplikací dodávané s Win.
21.8.2009 09:00 Michal Kašpar | skóre: 15
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
No ono to není přímo pomalé. Jen se to u mě chovalo prakticky stejně, jako totéž v nautilovi (ano to pomalé GTK). Takže mi přišlo lehce komické ono básnění o bleskovosti GUI ve Windows.
21.8.2009 10:49 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Nautilus má primitivní GUI. Na čemkoli složitějším je rozdíl víc než markantní.
21.8.2009 18:36 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jestli myslíš ty čárky uvnitř Notepadu, tak (pokud to nejsou kompresní artefakty videa jako o kus později, bohužel se to z toho příliš komprimovaného videa nedá tak poznat) to bych viděl na chybu ovladače grafické karty, stejně tak jako to blikání Exploreru, což jsem nikdy v životě neviděl ani na nejrozbitějších Windows s generickým VESA ovladačem
Ne, kompresí videa to není. Naopak capture videa ten efekt ještě o dost skryl, ve skutečnosti to bliká rychlejc/častějc.
Ovladač je poslední od AMD. Nic lepšího už nemám. Ještě je možná vadná karta, co já vim, ale to by se mělo projevit spíš v 3D.

Vidím, že používáš nějaký speciální vzhled místo továrního od Microsoftu, takže soudit Windows s takovými pochybnými blbinkami bůhvíodkud nebudu.
To není žádná pochybná blbinka ani specielní věc, je to naprosto normální .msstyle styl, tzn. to samý co tovární styl od MS, ale změněné bitmapy. Můžeš se o tom dočíst v dokumentaci. Na fukčnost to absolutně nemá vliv, když přepnu na MS-tovární styl, chová se to naprosto stejně. (nechce se mi dělat další video jen abych tohle dokázal, ale pokud mi nebudeš věřit, můžu)
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
mirec avatar 21.8.2009 06:36 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
No to, že nestíha prekresľovať firefox neznamená náhodou, že windows xp nepoužíva composite v takej forme ako v linuxe? Zdá sa mi, že sú tam všetky okná pokiaľ nie sú prekryté niečim polopriehľadným vykresľované priamo.
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
21.8.2009 08:28 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
No Windows XP z roku 2001 samozřejmě ne. Ani Linux to v roce 2001 neměl.
mirec avatar 21.8.2009 09:41 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tak prečo tu niektorí tvrdia, že windows má compositing už niekedy od windows 98?
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
21.8.2009 10:44 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
To tu nikdo netvrdí. Pleteš si úplně nesouvisející věci.
28.8.2009 01:30 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

To je asi reakce na mě. Spekuloval jsem, že nějaký zárodek kompozitního managera měli už Windows95/98. S ohledem na tehdejší hw velmi slušný výkon. Ani tehdy si u nativních aplikací (ie ne Firefox) nepamatuji viditelné překreslování oken při přejíždění jednoho přes druhé. Nebo už mě ta paměť úplně šárlí. Musel tam být minimálně nějaký backing store alespoň pro některá okna.

Wikipedia uvádí kompozitní manager až od Windows Vista. To se mi nezdá. Z vlastní zkušenosti vím, že už Windows 2000 uměli pravou průhlednost oken, to bez kompozitního managera nejde.

Pokud v tom někdo chce udělat jasno, tak to jen uvítám. Co jsem se jinde dočetl, tak zásadní vlastnost compozitního managera je kreslení do offscreen bufferu místo přímo na obrazovku.

Existuje pochopitelně celá řada jak to implementovat - v linuxu je mi známo 5 implementací - xcompmgr, kcompmgr, compiz (beryl, ), xfwm, kwin ale asi jich bude víc - Elinghtment? Metisse? Klasický problém linuxu a OSS - řada implementací ani jedna dotažená. Zdá se, že nejnadějněji má našlápnuto kwin. Předpokládám, že i u Windows to mělo nějakou evoluci.

Spekuloval jsem umyslně, chtěl jsem zlákat někoho, kdo o tom vý něco víc, zda by o tom něco nenapsal, hlavně srovnání implementací s Xorg.

28.8.2009 05:39 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Já tedy běžně pomalé překreslování oken při přejezdu jiných oken nad nimi vídám i ve Windows XP. Ale jenom u aplikací, které se prostě pomaleji překreslují (často takové ty multiplatformní věci, nevyužívající normální nativní GUI Windows).

Čili myslím, že to není v tom, že by už starší Windows používaly nějaký compositor, ale je to prostě v tom, že vykreslování ve Windows je tradičně daleko rychlejší než v Linuxu, a tím pádem tam tyhle artefakty byly mnohem méně k vidění. Okna se prostě i bez compositingu stíhala dostatečně rychle překreslovat.

Totéž ostatně i v Linuxu, když používáte archaické programy se starými toolkity jako lesstif nebo GTK+ 1.x. Ty byly taky daleko rychlejší než ty současné, moderní, takže tam bylo celkem plynulé překreslování při změně velikosti i při překrývání jinými okny.
28.8.2009 06:04 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Prostě když je vykreslování dostatečně rychlé, tak nepotřebujete žádé triky, aby to vypadalo rychle.

To mi připomíná, jak kdysi před lety byl pokus o vytvoření BlueEyedOS (kde je mu dnes konec?), který si dal za cíl vyvtvoření moderního desktopového systému (klonu BeOS) s rychlým GUI, založeného na Linuxu s X11 (tehdy ještě XFree86). Lidi se divili, proč používá X když chce mít rychlé GUI, ale autor v tehdy docela zajímavém, byť dnes už historickém článku (1. část, 2.  část) psal, že to je z praktických důvodů, kvůli ovladačům a tak, a že nic nebrání mít rychlé GUI nad X11, jenom se to musí dobře naprogramovat. A demonstroval to nějakou ukázkou, kde v X11 přetahoval okna nad sebou, a žádné artefakty tam nebyly. Tehdy o tom psal, že to pomalé překreslování je chyba toolkitů, které zbytečně překreslují všechno místo jenom oblasti, která potřebuje překreslit a tak. A to jeho demo bylo právě důkazem, že i obyčejné XFree86 je extrémně rychlé, když se to zoptimalizuje:

- zredukuje se komunikace mezi serverem a klientem

- využije se grafická paměť

- používá se minimální sada funkcí X11 (protože funkce X11 jsou komplikované a mají příliš velkou režii)

- překresluje se jen to, co je potřeba
Nicky726 avatar 20.8.2009 08:31 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Lze to nějak nastavit jako výchozí?
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
mirec avatar 20.8.2009 09:16 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Pri kompilácii. U gentoo užívateľov USE flag raster.
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
20.8.2009 09:32 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ale nevím, jestli je to moudré to nastavit plošně jako výchozí. Myslím, že i podle lidí od Qt to ještě není úplně vyladěné, v KDE se to prý nějak nastaví u programů, kde to je bezpečné – mně s tím dokonce u některých programů zatuhne X server, musím restartovat...

Ovšem největší pikanterie je, že když mám v Qt nastavené, ať používá motiv vzhledu GTK+, tak s rasterem se už ty widgety vzhledu GTK+ vykreslují mnohonásobně rychleji, než je vykresluje samotné GTK+. Takže to pak je takový zvláštní, exotický pohled, vidět okno nebo kartu vypadající jako GTK+, jak se vykreslí tak okamžitě, jak jsem to u GTK+ v životě neviděl...

Kéž by se raster dal použít i s GTK+.
mirec avatar 20.8.2009 09:52 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ja sa rasteru nebojím. Problémy mám skôr s -graphicssystem native. Raster u mňa ide trochu stabilnejšie takže je to super.
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
thingie avatar 20.8.2009 09:53 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Copak raster. Ale opengl!
Růžové lži.
mirec avatar 20.8.2009 10:03 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
OpenGL je ešte pomalšie než native ... O stabilite radšej pomlčím (intel).
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
thingie avatar 20.8.2009 10:06 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
To tu máme zase jedno objektivní pozorování a měření za druhým, zdá se. Achjo. Ono to je rychlé. Když to náhodou funguje, což ovšem nebývá moc často.
Růžové lži.
20.8.2009 10:05 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
OpenGL jsem taky zkoušel, a to je velká bizarnost. Fonty jsou nějak zdvojené, stínované, celé to při změně velikosti strašně bliká, některé věci se kreslí mimo, obsah oken se nepřekresluje, mizí, když se něčím překryje. Rychlost není o nic lepší než raster, spíš horší. A během chvilky to stejně spadne. Asi mám smůlu.
Nicky726 avatar 20.8.2009 09:57 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
A to nastavení u programů, kde je to bezpečné, lze udělat jak? Překompilovávat si KDEmod je na mém stroji na den práce, takže do toho se mi moc nechce... :-/
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
20.8.2009 13:07 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
den práce tebe nebo toho stroje? ;-)
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
Nicky726 avatar 20.8.2009 14:46 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Stroje, KDEmod má docela dobře vymakaný buildsystém, takže stačí napsat jeden příkaz a odentrovat.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
20.8.2009 13:35 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Nerozbité by mělo být akcelerované, ale nevím, o kolik by mělo to akcelerované být rychlejší.
20.8.2009 13:36 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Když o tom tak přemýšlím, tak by mě zajímalo, jak dobře je XRender podporované rozšíření. Když jsem dřív zkoušel benchmarky na toto téma, tak akcelerovaný XRender byl třeba 2x rychlejší než pixman, ale to mi přijde strašně strašně málo.
20.8.2009 16:10 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ono asi dost zavisi na tom, ktera operace z XRender se pouzije. Napriklad me vychazi vykreslovani alphablendovanych pixmap pomoci XRenderComposite asi tak 10x rychleji nez pomoci gdk_draw_pixbuf (kde to samozrejme zahrnuje krome samotneho compositovani take presun dat mezi xserverem a klientem.

20.8.2009 22:30 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jenže takto to právě posuzovat nejde, protože ve vašem testu zahrnujete i režii X protokolu a zbytečné přesuny dat. Další věc je ta, že gdk_pixbuf nepoužívá premultiplied formát, takže jde rychlost ještě víc dolů (a popravdě se mi nechce věřit, že by byly blittery v gdk_pixbuf napsané v SSE2).

Takže abych to shrnul, o kolik je XRender akcelerovaný grafickou kartou (jakákoliv trochu moderní) rychlejší, než implementace toho stejného blitteru v SSE2 na 2.4GHz procesoru? Nejradši srovnat to s testem rychlostí knihovny Fog :-)
20.8.2009 22:56 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Jasne. Zajimave by bylo mit softwarovou implementaci XRenderu pomoci podobneho efektivniho blitteru.

20.8.2009 23:10 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ale mi jde jen o tu HW implementaci. SW implementace prohraje vždy, protože režie X serveru a popřípadě kopírování pixmap na server zabere mnohem víc času, než to samotné vykreslení.
20.8.2009 23:14 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Myslel jsem to tak, ze se pak muze srovnavat HW implementace XRenderu se SW implementaci XRenderu, takze v obou bude zahrnuta stejna rezie.

 

21.8.2009 00:38 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tak pokud by v takovém srovnání HW implementace prohrála, tak by na tom byl XRender hodně špatně :-)

Podle mě by bylo lepší srovnat rychlost XRenderu vs. nějaká jiná optimalizovaná knihovna. Podle mě, aby byl XRender efektivní, musí být HW akcelerované úplně všechno, protože jediná neakcelerovaná (ale využitá) funkce může způsobit přelévání pixelů do grafické karty a zpět, a tento proces je údajně celkem drahý. Další věc je ta, že aby bylo možné objektivně posoudit rychlost, musí se vzít v úvahu i režie daných knihoven (co je mi platné, když knihovna A má vysoce optimalizovaný blitter, ale polygon vykreslí pomalej, než knihovna B, která nemá až tak optimalizovaný blitter, ale dispatching je oproti knihovně A bleskový). Například knihovny cairo a pixman mají vysokou režii na vykonání jakékoliv grafické operace (zavolá se zbytečně moc funkcí, neefektivní hledání fast-path funkcí, zbytečné vytváření dočasných objektů na heapu, atd). No a při použití XRender backendu může být ta režie ještě horší.

Chtěl jsem jen vznést otazník nad tím, jestli se perfektně optimalizovaná knihovna může vyrovnat nebo dokonce i překonat XRender, který má HW podporu. I SW grafická knihovna by přece mohla využít technologie jako jsou CUDA.
21.8.2009 07:43 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Jenze jakakoliv client-side sw renderovaci knihovna je omezena tim, ze data nakonec musi dostat na server. Takze srovnani samotne rychlosti renderovani by sice mohlo byt zajimave, ale pro vyvoj aplikaci je treba do uvahy zahrnout i vyse zminenou rezii. A ta muze byt v nekterych pripadech (pripojeni relativne pomalou linkou) radove vetsi u programu, ktery sam sw renderuje (a pokazde kopiruje cely vysledek na xserver), nez u programu, ktery pouziva xrender (a vsechny pixmapy uz ma na xserveru, jenom zadava prikazy co kam zakompozitovat).

21.8.2009 12:44 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Moment, neberme v úvahu síťový provoz - o tom naše diskuze není. Stačí použít rozšíření XShm, a máme celkem solidní základ pro double-buffering (ale opravdový, né ten, o kterém píšete, že je v GTK2, tj buffer se uvolní po nakreslení widgetu). Pak už je úplně jedno, jestli grafiku obstará XRender nebo si ji aplikace vykreslí sama. A pokud je XRender pomalý, tak to ta aplikace zvládne třeba i rychlej (vůbec netuším, jestli XRender akceleruje třeba gradienty, a pixman je implementuje strašně pomalu).
21.8.2009 13:24 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Moment, neberme v úvahu síťový provoz - o tom naše diskuze není. Stačí použít rozšíření XShm

Pokud by takovy rendering byl v soucasti nejake graficke knihovny, ktera by se pri vzdalenem provozu prepla na XRender, tak budiz. Ale jako vyvojar aplikaci bych se neodvazil se spolehnout na ciste client-side graficke rozhrani, prave z duvodu mozneho sitoveho pouzivani programu.

> (ale opravdový, né ten, o kterém píšete, že je v GTK2

Na tom neni nic ne-opravdoveho. Vyraz double-buffer se obvykle pouziva pro buffer pouzivany primarne za ucelem odstraneni problikavani pri prekreslovani. Buffer urceny pro server-side obsluhu expose se spis oznacuje jako backing store. Ten prvni ucel zmineny buffer v GTK2 dostatecne splnuje (i kdyz porad muze dochazet k trhani animaci), takze je korektni to nazyvat doublebuffferingem. Kdyz se do okna nekresli, neni doube-buffer potreba a muze se klidne uvolnit.

BTW, me by se nejvic libilo takove reseni double bufferingu v X, kdyz by existoval jeden spolecny buffer stejne velky jako framebuffer a aplikace by ke vsem svym window handlerum mohly dostat 'stinove handlery', ktere by pracovaly uplne stejne jako normalni window handlery, akorat by namisto do framebufferu vyvolavaly kresleni do doublebufferu. Pak by aplikace signalizovala commit a X server by prislusnou cast doublebufferu prekopiroval do framebufferu behem vsync. To by umoznilo neblikave kresleni a pritom by to melo limitovanou spotrebu pameti (a nezvysovalo dobu obsluhy expose eventu cekanim na alokaci bufferu).

21.8.2009 17:23 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jenže většina uživatelů chce rychlý desktop. Vzdálené X jsou sice zajímavá věc, ale díky tomu všemu je Xlib taková jaká je (asynchronní, komplikovaná, neumí renderovat do klientského bufferu (takže je potřeba další knihovna, který to umí, popřípadě XShm=další synchronizace a komplikace), atd...), a vznikají další a další knihovny k ulehčení renderování / vytváření UI. GUI aplikace většinou potřebují i načíst nějaký ten obrázek, udělat z něho pixmapu, atd. A to v případě práce s X není vůbec jednoduché. Jasně, existují toolkity, ale vevnitř je to úplně stejné (komplikované API pro práci x Xlib, pixmapama na serveru, atd).

A ještě jedna věc, výraz backing store jsem viděl jen v terminologii XServeru, třeba ve windows jsem tento pojem nikdy neslyšel. Běžně používaný double-buffer se normálně neuvolňuje. To, o čem mluvíte bych nazval jako buffered-rendering (renderování do bufferu).

Jako já nemám nic proti linuxovému desktopu (iXek se stejně nezbaví), ale jsem velice zvědavý na to, až google pustí jeho windowing-system. Jaký výkonnostní rozdíl bude mít windowing-system dělaný synchronně a nesíťově vs. X11. Protože jak to tak poslouchám, tak zastánci říkají, že v tom nebude žádný rozdíl, ale to je přece blbost.
21.8.2009 20:37 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> tomu všemu je Xlib taková jaká je:

> (asynchronní,

To je vyhoda. Jak uz jsem zminoval - OpenGL je take asynchronni, moderni graficke karty jsou take asynchronni,

> komplikovaná

To je spis z duvodu dlouhe historie, nez z duvodu vzdaleneho sitoveho provozu. Kdyby se odstranila velka cast historickych funkci, podpory paletovych rezimu, z renderovacich nechal jen jen XRender a ten lepe integroval, tak by vznikl jednoduchy, ale stale vzdalene schopny sitoveho provozu.

> neumí renderovat do klientského bufferu

Programatorovi je celkem jedno, jestli na renderovani do klientskeho bufferu pouzije Xlib, nebo nejakou jinou knihovnu, kdyz to bude dobre integrovane.

> pixmapama na serveru

Jak to vlastne vypada ve Windows, jsou tam nejake rozdily mezi uzivatelskyma pixmapama  a 'serverovyma' pixmapama?

Tohle rozdeleni ma IMHO velky smysl i na jednom pocitaci - klientska pixmapa jako pixmapa, do ktery program ruzne zasahuje, zatimco 'serverova' pixmapa je takova, ktera se preda grafickemu subsytemu (a ten ji treba muze natahnout do pameti graficke karty). Kdyz pak program opakovane vola, ze chce kopirovat oblast z tehle pixmapy, graficky subsytem muze pouzit natazenou pixmapu v graficke karte a nemusi kontrolovat, ze ji uzivatel mezitim treba nezmenil.

> Jaký výkonnostní rozdíl bude mít windowing-system dělaný synchronně a nesíťově vs. X11

Ono take jde hlavne o to, jestli to bude udelane dobre vs. spatne. Nejvetsi problem X.org neni ani tak komplikovany X protokol, ale spatne drivery.

22.8.2009 00:36 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
asynchronní, to je vyhoda...
Ono jak se to vezme. Vy to srovnáváte s openGL, ale openGL je jen grafická část story, u které ta asynchronnost opravdu nevadí (je to kvůli výkonu), protože se jedná jen o serializaci příkazů GK. Moderní grafické knihovny už dnes ani nenabízí funkce typu getPixel() - dobře víme proč:) Například v knihovně Fog probíhá renderování taky asynchronně, pokud se používají vlákna, a je to opravdu jedinná možnost, pokud je backend podporuje takový styl renderování.

Jenže X11 není jenom grafická knihovna, je to okenní systém, a u okenního systému člověk normálně nepočítá s tím, že nechá namapovat okno, a ono to nemusí být "hned".
Programatorovi je celkem jedno, jestli na renderovani do klientskeho bufferu pouzije Xlib, nebo nejakou jinou knihovnu, kdyz to bude dobre integrovane.
Myslíte si, že současná situace je dobrá (tedy jsou dobře integrované a provázané knihovny)? Třeba mi přijde naprosto šílené gdk_pixbuf a cairo. Obě knihovny umí renderovat do bufferu, ale nejsou schopné se domluvit na pixel formátu.
Jak to vlastne vypada ve Windows, jsou tam nejake rozdily mezi uzivatelskyma pixmapama a 'serverovyma' pixmapama?
Ve Windows tyto problémy neexistují, protože tam žádné serverové pixmapy nejsou. Na grafiku se většinou používá DIBSECTION, což je buffer, do kterého můžete kreslit přímo, nebo použít GDI/GDI+/Cairo/cokoliv (je to buffer). Ještě tam je DDBITMAP (Device Dependent Bitmap), což by se dalo přirovnat k pixmapám na XServeru (obsah by měl být uložen v GK, ale nikdy jsem to nepoužíval, takže ani nevim jak to funguje).
Ono take jde hlavne o to, jestli to bude udelane dobre vs. spatne.
No na tom se shodnem :)
Nejvetsi problem X.org neni ani tak komplikovany X protokol, ale spatne drivery.
Zkusme si položit otázku, jestli ty drivery netrpí i návrhem XServeru (myslím to tak, že se špatně píší). Já jsem se na zdrojáky XOrg díval, a myslím si, že to je celkem komplikovaný systém. Některý kód je starý přes 15 let, a od té doby bez změny. Hodně zdrojáků v XOrg mi připadá spíš jako referenční implementace, než něco, co je optimalizované pro rychlost a dá se snadno udržovat - Třeba zmíněný XRender, když se podíváte dovnitř (dnes pixman), tak zjistíte, že výkon při návrhu knihovny vůbec nebyl důležitý - a to je podle mě chyba.
22.8.2009 08:05 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Myslíte si, že současná situace je dobrá (tedy jsou dobře integrované a provázané knihovny)?

Nevim, client side rendering jsem nikdy nepouzil, takze tam situaci moc neznam. Je pravda, ze gdk_pixbuf pouziva reprezentuje pixmapy v jinym formatu, nez XRender, coz je docela hloupe.

> Zkusme si položit otázku, jestli ty drivery netrpí i návrhem XServeru (myslím to tak, že se špatně píší).

Nevim, to jsem do podrobna nezkoumal, ale myslim, ze ovladace jsou od toho celkem odstinene - implementuji relativne uzke renderovaci rozhrani (EXA) site na miru XRenderu.

> Třeba zmíněný XRender, když se podíváte dovnitř (dnes pixman), tak zjistíte, že výkon při návrhu knihovny vůbec nebyl důležitý - a to je podle mě chyba.

Souhlasim.

20.8.2009 19:40 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

 

Problém s pomalostí X11 a generováním mnoha událostí se dá řešit i tak, že se nebude vytvářet moc zdrojů na straně X serveru (takže jen top-level okna, double buffer, toolkit si může obsah v okně řídit sám).

Moje řeč! Moje řeč. Tohle jsem měl ny mysli tím seškrtáním.

Výhoda je taková, že tento způsob je rychlý, asynchroní protokol už tak nevadí, protože událostí a požadavků není moc, a aplikace je rychlá na běžném desktopu.

Tak to už si tak jistý nejsem. Apple ho také používá a asi ne pro legraci. Podle mě by měla existovat možnost se do synchronního módu se minimálně přepnout. Čemu vlastně synchronní mód vadí? Kromě podpory síťové vrstvy v X.

Nevýhoda je ta, že síťový provoz až tak efektivní není, a další věc, že

Síťový provoz, remote X, eeeh, zapomeňmě na to. Kolik lidí to vůbec používá? Na remote desktop tu jiné technologie (VNC, NX, RDP..) Kvůli takové vzácně používané vlastnosti nemá cenu si rozkorejnit design a obětovat rychlost pro 99% ostatního použití. Jestli se kvůli tomu opravdu musí přesouvat komplikovaně data a činnost mezi serverem, to nemá cenu.

z X serveru se už stává jen jednoduchý poskytovatel pro vytvoření oken a generátor událostí. Tento způsob používá nové Qt a já ho v knihovně Fog používám taky (pro mě to má i výhody v přenositelnosti)

Moje řeč! Proč to vyslovujete takovým omluvným tónem. U toho by měl jeden jásat ;) Konečně. Já jsem si představoval, že to takhle funguje dávno.

 

 

Jsem se trochu rozepsal, no...:)

Jen tak dál, tohle byl jeden z nejhodnotnějších příspěvků tady. Nechcete to napsat nějaký článek? Já vám napíšu jaké mám mylné představy, jaké má možná řada dalších lidé představy, že to funguje a vy to uvedete na pravou míru ;-) Kdo kreslí primitivy. Jaký je řetězec událostí, aplikace chce nakreslit čáru - kdo a kde ji skutečně nakreslí (buffer? přímo do paměti videokarty?) jak se to bude lyšit když je apliakce v Qt, Gtk. S compozite, bez kompozitu. Co když to nebude čára, ale písmeno, obrázek, polygon. Co všeno umí X, co se děje na straně X serveru a co na straně apliakce. Jaké informace si předají. Předá Qt aplikace obsah celého okna jako jednu velkou bitmapu a řekne X, tohle je můj obsah, prosímtě, jak budeš mít čas, tak to vykresli. Nebo je to obsah primitiv (řekněme formulář bez obrázků, tlačítka a písmenka)? Jakou formou si to předají pokud je to bitmapa? Sdílená paměť? Doufám nestěhují nějaké bloby socketem!?!?

 

Pokud možno neplést do toho síťování. 

Jetli nevíte o čem psát, dám vám seznam svých otázek a asi částešně naivních představ, jak to funguje :)

20.8.2009 20:06 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Čemu vlastně synchronní mód vadí?

Asynchronni rezim ma znacne vyhody z hlediska rychlosti. A to nejenom pres sit, ale i na jednom pocitaci. Rychlostni problemy synchronniho protokolu by sli omezit presunutim renderovaci casti do jadra (to nikdo nechce) nebo primo do kresliciho procesu. Ale nema to moc smysl - OpenGL a hardwarove rozhrani dnesnich grafickych karet je take asynchronni.

> Síťový provoz, remote X, eeeh, zapomeňmě na to. Kolik lidí to vůbec používá?

Spousta. Navic predstava, ze pozadavek na sitovy provoz by nejak automaticky musel zpomalovat implementaci, je nepodlozena. Napriklad OpenGL je take navrzene tak, aby slo snadno sitove provozovat. A funguje to tak, ze kdyz bezi lokalne, pouzije se direct rendering, kdyz vzdalene, pouzije se GLX (zapouzdreni OpenGL prikazu do X protokolu).

> Kdo kreslí primitivy. Jaký je řetězec událostí, aplikace chce nakreslit čáru.

Doporucuji si alespon prolistovat 'Xlib - C Language X Interface' od J. Gettyse a R. Scheiflera a 'The Xrender Library' od K. Packarda.

> Jakou formou si to předají pokud je to bitmapa? Sdílená paměť? Doufám nestěhují nějaké bloby socketem!?!?

Jsou obe moznosti. Obcas se uvadi, ze pro male objekty vychazi ten socket vicemene nastejno.

20.8.2009 20:40 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

 

Asynchronni rezim ma znacne vyhody z hlediska rychlosti. A to nejenom pres sit, ale i na jednom pocitaci.

Nezlobte se, nějak se mi tomu nechce věžit. Jako že klientskou apliakce není informovaná o změnách včas a hned jak se stanou? No na "komunikaci" tím ušetříte z tohoto pohledu je to rychlejší, ale o rychlosti z pohledu uživatele se mluvit nedá, u alipkace s častou změnou obsahu (animace, důsledek resize a další) se pak jeví jako subjektivně pomalejší, zadrhává. A právě o subjektivní vnímání v GUI jde. To není jako v batch procesech.

> Síťový provoz, remote X, eeeh, zapomeňmě na to. Kolik lidí to vůbec používá?

Spousta. Navic predstava, ze pozadavek na sitovy provoz by nejak automaticky musel zpomalovat implementaci, je nepodlozena. Napriklad OpenGL je take navrzene tak, aby slo snadno sitove provozovat. A funguje to tak, ze kdyz bezi lokalne, pouzije se direct rendering, kdyz vzdalene, pouzije se GLX (zapouzdreni OpenGL prikazu do X protokolu).

Kdo! Kde! Můžete být konkrétnější. Já něco takového pamatuji v roce 1998 nebo 98? V jedné učebně VŠE na Jižním městě. Vyučoval se na tom základy tvorby webu (nebo jak se to jmenovalo). Fungovalo to docela OK, tehdy člověk od GUI moc nečekal, většina učeben měla Win 3.11 a ty byly s GUI tak na stejné úrovni. Když jsem v r 2001 promoval, byly tam už tam samozřejmě zpátky Windows.

To bylo poprvé a naposledy kdy jsem viděl remote X v provozu.

Mimochodem, vy jste někde viděl masovější nasazení linuxového desktopu? Kromě domácích uživatelů a ti remote X upotřebí asi nejméně.

A pokud někdo potřetřeboval remote X opravdu nešlo použít nějaký remote desktop (VNC, NX, RDP)?

 

> Kdo kreslí primitivy. Jaký je řetězec událostí, aplikace chce nakreslit čáru.

Doporucuji si alespon prolistovat 'Xlib - C Language X Interface' od J. Gettyse a R. Scheiflera a 'The Xrender Library' od K. Packarda.

Nejsem si jistý jestli mě popis API prozradí co se děje uvnitř. To jde trochu nad rámec API.

Pročetl jsem si články o X11 a Xlib na Wikipedii, je tam o tom čeho je Xlib schopná, ale ne jak a co z toho je dnes reálně používáno, jak a co z Xlib používají Qt a Gtk.

Tak jako tak, populárně pojatý článek by se hodil. Když to dokázal Grygar s Astronomii, proč by to nešlo i s teorií a praxí kolem X.

 

Grunt avatar 20.8.2009 20:44 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Kdo! Kde!
Já a přímo tady.
A pokud někdo potřetřeboval remote X opravdu nešlo použít nějaký remote desktop (VNC, NX, RDP)?
Ne, ani omylem!
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
thingie avatar 20.8.2009 20:45 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Bylo by vhodné podotknout, že NX není samostatný nový protokol, který by s X neměl nic společného.
Růžové lži.
20.8.2009 21:58 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Nezlobte se, nějak se mi tomu nechce věžit.

Je to jednoduche. V tomto kontextu znamena synchronni rezim to, ze aplikace posle pozadavek a pak ceka, nez ho server vyridi, a do te doby neposle dalsi pozadavek. Asynchronni rezim znamena to, ze aplikace posila pozadavky a neceka na odpovedi, ty pak zpracovava v hlavni smycce jak prichazeji. Rychlost synchronniho rezimu je omezena dobou roundtripu. A ta  v meziprocesorove komunikaci je radove v ms. Rezie, spojena s jendim prepnutim kontextu by u znacne casti pozadavku mnohonasobne prekrocila praci spojenou s vyrizovanin pozadavku. A tech pozadavku pro prekresleni jednoho okna prohlizece jsou treba stovky.

Krom toho by to zbytecne omezovalo moznost vyuziti hardware - akceleratory grafickych karet fungovaly synchronne nekdy v prvni polovine devadesatych let. Dnes graficke akceleratory funguji asynchronne. Vsechny rozumne protokoly, kde jde o rychost, jsou asynchronni.

> Kdo! Kde! Můžete být konkrétnější. Já něco takového pamatuji v roce 1998 nebo 98?

Myslim bezne desktopove uzivatele. Treba zrovna dnes jsem poustel pomoci vzdaleneho X program z jineho pocitace, protoze jsem ho potreboval otestovat na amd64 architekture a u sebe mam x86.

> A pokud někdo potřetřeboval remote X opravdu nešlo použít nějaký remote desktop (VNC, NX, RDP)?

VNC je radove horsi reseni. RDP funguje vubec pod Linuxem? Kazdopadne je to celkem jedno. Jak uz jsem psal - to, ze protokol je navrzen tak, aby fungoval vzdalene, ho jen minimalne limituje v lokalnim provozu.

28.8.2009 12:35 miso | skóre: 36 | blog: iSCSI_initiator_howto | Praha
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

 

RDP funguje vubec pod Linuxem? Kazdopadne je to celkem jedno. Jak uz jsem psal - to, ze protokol je navrzen tak, aby fungoval vzdalene, ho jen minimalne limituje v lokalnim provozu.

 

Pozri projekt NOMAD (S dlhodobejsou prevadzkou nemam skusenost, ale fungovat - funguje ;-)).

Project Satan infects Calculon with Werecar virus
Grunt avatar 20.8.2009 20:28 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Síťový provoz, remote X, eeeh, zapomeňmě na to. Kolik lidí to vůbec používá? Na remote desktop tu jiné technologie (VNC, NX, RDP..)
Tak takové výroky mě dovedou rozpálit do ruda. Místo síťových Xek používat bazmeky jako VNC a podobné. Proč rovnou defaultně nezakážeme SSH a BASH? Vždyť to také 99% BFU nepoužívá a jen to zdržuje a zabírá místo v paměti.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 20:55 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ne emoce ale racionalita má promlouvat při posuzování technologie. Emoce si nechte pro přítelkyni. Dopadnete jako legendární docent na VŠE J.J.Kastl který se slzami v očích loučil s původními alfanumerickými terminály, když je škola likvidovala a nahrazovala PC. Nahlas si jim stěžoval, že "..on už jim nestačí text! Oni už teď chtějí všude obrázky!.. " a tak v tomhle smyslu. 

SSH mám na laptopu zakázaný. Nevím proč by mi měl běžet, nikdy jsem ho nepoužil. Na domácím serveru samozřejmě ano.

VNC co vám na něm vadí? Já vím, Microsoftí RDP je lepší, ale on VNC zase tak beznadějný není. Já výhradně používám VNC na lokální server. Zkoušel sem i vychvalovaný NX, ale aby pravdu řekl, neudělal na mě zázračný dojem, vrátil jsem se k VNC.

Pokud by remote featura v X nijak neovlivňovala ostatní funkcionalitu, nezpomalovala, nezkomplikovala design, vývoj a vylepšování X, pak pro mě za mě, ať se to udržuje i kdyby to používalo < 1% lidí. Třeba nějaký nepovinný plugin do X. Já jsem přejícný a menšinám nakloněný člověk, pokud neomezují druhé. 

Grunt avatar 20.8.2009 21:17 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Dopadnete jako legendární docent na VŠE J.J.Kastl který se slzami v očích loučil s původními alfanumerickými terminály, když je škola likvidovala a nahrazovala PC. Nahlas si jim stěžoval, že "..on už jim nestačí text! Oni už teď chtějí všude obrázky!.. " a tak v tomhle smyslu.
Ale vždyť Vy chcete přesný opak. Zbavit se PC ve prospěch terminálu, protože když se to písmo musí renderovat(a nerenderuje se v kernel-spacu) tak to snad musí být pomalé. Vy se chcete zbavovat určité funkce jen protože to Vy a dalších 99% lidí v životě nevyužijete(což je jen Vaše mínus). A ještě prosím nadávejte GTK vývojářům za odebrání funkčnosti, protože to 99% BFU nepotřebuje. Vždyť Vy nejste vůbec jiný.
VNC co vám na něm vadí? Já vím, Microsoftí RDP je lepší, ale on VNC zase tak beznadějný není. Já výhradně používám VNC na lokální server.
Nevím jak to dělají ty moderní, ale v dobách kdy se s VNC a Remote Administrátorem hrál já, tak to kopírovalo bitmapy z framebufferu a ty posílalo. Posílání eventů myši a klávesnice byli stejně hnusné hacky. To se s X protokolem absolutně nedá srovnávat. Nehledě na to, že bez běžícího serveru by se neposílalo nic a o posílání jen určitých oken bych si také mohl nechat jenom zdát. A určitě se najde více funkcí.(To vážně používáte? To k serveru stavíte monitor a cpete do něj grafiku, rozjíždíte XDM,…?)
Zkoušel sem i vychvalovaný NX, ale aby pravdu řekl, neudělal na mě zázračný dojem
Neplete si čirou náhodou NX s Xkama po síti(XDMCP a nebo ručně)?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.8.2009 02:04 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Myslím, že vím dost přesně co chci - co nejrychlejší, nejekonomičtější, snadno konfigurovatelný, profesionálně vypadající desktop. Nechci vidět žádné artefakty. Nechci aby mi tam strašilo něco co nepoužívám co ho potenciálně zpomaluje, co komplikuje vývoj driverů, aplikací a atd. Síťovou podporu přímo v X, jako nepovinný plugin - pak bezevšeho.

Diskuse nad stavem Gtk, to raději založte nový článek, to už by jsme  se dostali hodně jinam. Navíc pracuji primárně s KDE, takže k otázkám na Gtk nejsem ten pravý odborník. Netuším co máte s Gtk na mysli.

Ad VNC - jestli jsem pochopil okolní diskusi, pak zase takový rozdíl v přenášených datech mezi X protokolem a VNC není. Řada aplikací si vykresule obsah sama a posílá ho na server jako bitmapu. I pokud aplikace si sama obsah nekreslí a posílá obsah "vektorově", stejně i pak, při komplexnosti dnešního GUI, při množství bitmap, ono to vychází téměř na stejno.

Teď mě dokonce napadá, že jsem četl nějaké novější měření, kde porovnávali množství přenášených dat (vnc proti X) a vnc vyšlo jako výtěz, je úspornější díky použité kompresy (myslím že umí i jpeg)! Zkusím ten zdroj najít.

Mám obavu, že váš názor na VNC jsou spíše tradované předsudky.

NX (NoMachine)

Nojo, asi máte pravdu, měl jsem za to že mají vlastní protokol a on je to jen speciálně komprimovaný X. Vida, to se moc neukázali, to tím spíš potvrzuje moje slova v předchozích odstavcích.

Grunt avatar 28.8.2009 10:39 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Myslím, že vím dost přesně co chci - co nejrychlejší, nejekonomičtější, snadno konfigurovatelný, profesionálně vypadající desktop.
Co jiného by také mohl normální člověk chtít, že?
Nechci vidět žádné artefakty. Nechci aby mi tam strašilo něco co nepoužívám co ho potenciálně zpomaluje, co komplikuje vývoj driverů, aplikací a atd. Síťovou podporu přímo v X, jako nepovinný plugin - pak bezevšeho.
A můžu se Vás zeptat, kde jste přišel na to, že za ty artefakty a nebo zpomalováním stojí síťová vrstva Xorg? Vždyť pokud se to nepřenáší po síti, tak je to socket na který je připojena z jedné strany Xková knihovna klientské aplikace a z druhé strany XServer a komunikují spolu X11 protokolem. Nechápu jak byste si to teda představoval? X11 bez X11 protokolu? Stačí si zapnout xev a podívat se. Vždyť to jsou většinou jen souřadnice myši a klávesové eventy a z druhé strany pointery v případě, že používáte XShm. Tam není moc místa na overhead. Nebo nechápu jak byste si to teda představoval. Aby klientská aplikace dostávala přímo souřadnice z myši, klávesy přímo z terminálu skrze stdio a kreslila sama přímo do framebufferu a jediné co by tomu všemu stálo v cestě je max. jedna knihovna? Jo počkat, ono vlastně něco takového existuje už pěkně dlouho. Jmenuje se to DirectFB, takže stáhněte a klidně můžete zkoušet a porovnávat ten Váš imaginární overhead.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Grunt avatar 28.8.2009 10:48 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Diskuse nad stavem Gtk, to raději založte nový článek, to už by jsme se dostali hodně jinam
Omlouvám se, chtěl jsem říct vývojářům GNOME. Těm se furt vytýká, že odstraňují funkcionalitu aby nemátla uživatele, ale vždyť Vy nechcete absolutně nic jiného. Že byste byl takový pokrytec?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Grunt avatar 28.8.2009 13:26 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Teď mě dokonce napadá, že jsem četl nějaké novější měření, kde porovnávali množství přenášených dat (vnc proti X) a vnc vyšlo jako výtěz, je úspornější díky použité kompresy (myslím že umí i jpeg)! Zkusím ten zdroj najít.
Ano, tak teď jste na to kápl. Místo přímého odesílání entit sniffovat buffer, převádět do JPEGu a posílat ten. To si radši spustím x264.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 22:01 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> SSH mám na laptopu zakázaný. Nevím proč by mi měl běžet, nikdy jsem ho nepoužil.

Treba proto, ze je to jeden z nejjednodussiho zpusobu sdileni souboru (pomoci integrovaneho SFTP).

> VNC co vám na něm vadí?

Proc neco tak neschopneho jako VNC, kdyz mame mnohem lepsi X protokol?

28.8.2009 02:25 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

SSH je samozřejmě přítomná jako knihovana v řadě aplikací. Já měl na mysli server pro vzdálený shell, tj běžící sshd. Huh, jak jsem se vlastně od X dostali k ssh? takže raději tematicky zpět.

VNC - viz moje odpověď Gruntovi. Mám podezření, že ona strašná neefektivita VNC je tradovaný mýtus. VNC vyvíjí a roky stará negativní zkušenost nemusí být už relevatní. A pokud VNC.

A pokud VNC není 100% efektivní pak:

a) Zvážit jak moc se remote desktop používá a zvážit jestli pro nárazouvou činnost opravdu VNC není dostatečný.

b) Vylepšit VNC. Že to nejde? Tak se mrknout se ke konkurenci na RDP a vzít si pozitivní příklad. Klient RDP v linuxu je.

Komplikovat kvůli vdálenému přístupu jádro X, to je ta úplně posledna varianta. Jádro má být ta nejoptimalitovanější část, plně koncetrovaná na hlavní činnost. Rychlý, reaktivní desktop. To je Unixová filozofie - dělat jednu věc a to dobře. Síťové rozšíření, jako plugin přidávající specializovanou činnost, to pak prosím, to už nic nenamítám. Aktivuje si ho, kdo ho potřebuje.

Grunt avatar 28.8.2009 13:21 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
VNC - viz moje odpověď Gruntovi. Mám podezření, že ona strašná neefektivita VNC je tradovaný mýtus. VNC vyvíjí a roky stará negativní zkušenost nemusí být už relevatní. A pokud VNC.
Tak si dovolím citaci:
Kompletní VNC systém se skládá z klienta, serveru a komunikačního protokolu. VNC server je program, který sdílí svoji obrazovku. VNC klient (viewer) je program, který zobrazuje sdílenou plochu a ovládá server. VNC protokol (RFB) používá bitmapové řešení, kde každý pixel má své souřadnice, kde plocha se bere jako jeden obrázek, na který se malují objekty a jako celek se to pošle klientovi. Přenášejí se pouze změny (například pohyb myši, psaní textu, zobrazování videa). V praxi pohneme kurzorem, server si přebere souřadnice, a na hostitelském počítači se provede pohyb kurzoru, který se pak zpětně promítne do klienta.
Tak se mrknout se ke konkurenci na RDP a vzít si pozitivní příklad. Klient RDP v linuxu je.
Nechci Vám do toho kecat, ale IHMO je RDP tak rychlí z toho důvodu, že pracuje na stejném principu jako Xka. Tedy žádné sniffování bufferu a odesílání změn.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Grunt avatar 20.8.2009 20:31 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Kromě podpory síťové vrstvy v X.
Dle mého názoru, by naopak synchronizace síťovému provozu moc ulehčila.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
thingie avatar 20.8.2009 20:42 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
To je ale krátkozraké. Kde se stále bere ta utkvělá představa, že vzdálená Xka a síťování jsou něčím co nějak zásadně zesložiťuje Xka, a má za vinu devět deseti problémů, a strašně moc by se vyhrálo, kdyby to tam nebylo? To je blbost, a nikdo to zatím nedokázal.
Růžové lži.
Grunt avatar 20.8.2009 20:46 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
To je ale krátkozraké. Kde se stále bere ta utkvělá představa, že vzdálená Xka a síťování jsou něčím co nějak zásadně zesložiťuje Xka, a má za vinu devět deseti problémů, a strašně moc by se vyhrálo, kdyby to tam nebylo?
Těžko říct. Proč mám furt takový pocit, že ta většina to donekonečna srovná se způsobem jak to dělá Windows? Asi protože něco takového Windows nemá?(RDP nepočítám)
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 21:01 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Protože GUI dělají dobře. Protože jsou jejich uživatelé s GUI spokojeni. Protože dělají řadu věcí dobře, viditelně lépe a už relativně dlouho, a nejen marketingem se setřeli konkurenci.

Mimochodem, jak je na tom Apple s OS X. Taky tam mají síťovou mezivrtstvu?

Grunt avatar 20.8.2009 21:08 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Mimochodem, jak je na tom Apple s OS X. Taky tam mají síťovou mezivrtstvu?
Může mi někdo rozumně prosím vysvětlit, co furt máte proti té síťové vrstvě a X Serveru v user-space? Já už začínám pomalu mít pocit, že už ani nejde o tu pomalost ale o toto.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 21:14 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

No za devět z deseti asi ne, ale i kdyby za jeden z deseti, tak to už stojí za úvahu to vypustit. A to jsem k v tom hodnoceni shovívavý. Zvláště přihlédneme li, že remote X používá < 1% a ani ti ho dost možná požívat nemusí neb jsou tu alternativy, a tohle < 1% negativně ovlivňuje 99% uživatelů. I kdyby zhoršení jen o těch deset procent! Podporovat něco takového postrádá racionální základ. 

> To je blbost, a nikdo to zatím nedokázal

Nikde jsem ani neviděl studii prokazující opak. Možná jen že se tomu věnuje málo pozornosti. Málo kdo rozumí vnitřnostem Xek. Stačí se mrknout tady do dikuse. Mě nevyjímaje.

Grunt avatar 20.8.2009 21:19 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ještě jednou ne, ne, ne! Ani omylem. Běžte (si) do…Windows.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.8.2009 02:57 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ale no tak. Přeci se nebudeme kvůli odlišnému názoru posílat ...někam. Stějně tak já vás můžu poslat "s tím ultrakonzervatismem běžte (si) do CP/M, tam se rozhodně kompozitního manažera v Xorg bát nemusíte" ;-)

Nikdo z nás dvou nemá větší či menší právo být víc "v" linuxu a posílat jiné "z" něj.

Já bych osobně viděl více lídí v linuxu. Linux for Everyone. Linux má na víc než na 1%. Víc lidí, víc vývojářů, lepší programy i pro nás, lepší a lépe odladěné drivery v Xorg.

Grunt avatar 28.8.2009 12:55 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
"s tím ultrakonzervatismem běžte (si) do CP/M, tam se rozhodně kompozitního manažera v Xorg bát nemusíte"
Tak to zas pozor. Kdo mě zná, tak ví, že jsem pro projekty jako FBUI všemi deseti(Je to asi to co si představujete, aplikace posílá přes volání jádra tvary, které potom jaderný modul vykresluje přímo do framebufferu…obdoba Windowsí varianty). Ovšem v opodstatněných případech(embedded třeba). Mam ještě v živé paměti hádku s pavlixem, který se mě snažil přesvědčit, že v embedded je něco takového naprosto nepotřebného, protože 32MB čipy jsou dnes za babku, síťová vrstva je tam plus a user-space dovolí mít přihlášených víc uživatelů, usw. A teď se mě zase snažíte Vy přesvědčit, že u desktopu s nadupanými deseti-jádry, 8GB paměti, 64-bity, HW akcelerátory a modrou prostatou je síťová vrstva a vykreslovadlo v user-space zbytečný overhead. Jsem asi nějaký vadný a nebo mám poruchu osobnosti nebo co. A nebo mi schází ten správný inženýrsko-manažerský smysl a pohled na věc?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
thingie avatar 20.8.2009 21:24 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Achjo. Ta čísla 1 a 99 % jsou taky akorát nepodložená blbost. Především, ta síťová transparentnost je značně ústřední koncept celých X11, „vypustit to“ při současném zachování toho protokolu jako takového je strašně hloupé. Všimněte si už jenom toho, že tomu říkáme protokol, a ne grafické API.

Ono by se asi například dalo vzít za příklad typickou komunikaci X klienta a serveru na jednom stroji a hledat jakýkoliv prostor pro úsporu jiným řešením. Kdyby skutečně byl ten koncept tak špatný a neúsporný (pro tento případ), muselo by se jistě najít spousta otřesností a neefektivity, ale právě třeba to nikdo neukázal.
Růžové lži.
Grunt avatar 20.8.2009 21:29 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Všimněte si už jenom toho, že tomu říkáme protokol, a ne grafické API.
Huh, tak to mi naskočila husina a jen jsem se otřepal. Takového dne se obávám víc než toho soudného.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.8.2009 02:45 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> síťová transparentnost je značně ústřední koncept celých X11

Nevím jak koncept, ale primárním účelem X serveru je poskytovat interaktivní grafický desktop. Všechno okolo, jako síťování, je balast navíc, o to se mají starat specializované moduly, pluginy, knihovny, apliakce. Xorg tak porušuje jedno ze stěžejních Unixových konceptů - dělat jednu věc a dělat ji dobře.

> tomu říkáme protokol, a ne grafické API.

Všechny* aplikace používají volání Xlib (případně xcb), takže klidně můžeme zůstat a dívat se na to jako na API. Xka bez X protokolu, proč ne! Když to implementuje řádně Xlib, pak na tom budou chodit všechny současné aplikace, proč ne, mě by to jen lákalo. Pokud to něčemu pomůže, zrychlí to činnost a neomezí vlastnosti, pak ať klidně zahodí celou tu protokolou vrstvu.

*Jestli o nějaké používané aplikaci, která nepoužívá (přímo, nepřímo) Xlib (resp. xcb) víte, sem s ní! Přímé volání X protokolu to jsem viděl leda tak v demo ukázce v jednom tutorialu na rootu.

thingie avatar 28.8.2009 07:47 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
To je úplně špatný pohled. Primárním účelem X serveru je implementovat X protokol, nečekaně. Já nechápu, co je na myšlence, že síťová transparentnost je ústřední vlastností celého protokolu, která tam prostě „zadarmo“ je, tak pobuřující. Znova se ptám, kde se kruci furt bere ta představa, že je to něco navíc, čeho je nutné se zbavit?

Jenže to ničemu nepomůže, nezrychlí a omezí. Co by se změnilo? Kde konkrétně by se něco zlepšilo? Jak se třeba bude bavit taková aplikace s X serverem, když ne X protokolem přes unixový nebo síťový socket. Vrazíte tam k tomu dbus? To je teda pomoc. Nebo nahradíte všechny X funkce syscally a půjdete přes jádro (kam asi budete muset dát i X server, aby to mělo význam)? Taky výhra.
Růžové lži.
20.8.2009 22:10 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> a tohle < 1% negativně ovlivňuje 99% uživatelů.

A to je naprosto nepodlozene tvrzeni. Viz mnou uvadeny priklad s OpenGL.

Grunt avatar 20.8.2009 20:49 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jestli se kvůli tomu opravdu musí přesouvat komplikovaně data a činnost mezi serverem, to nemá cenu.
Ano, musí. A z toho důvodu bylo vymyšleno rozšíření XShm(X Shared Memory). Klient to zapíše do bufferu a pak už se dál předávají jen pointery.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 20:58 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

No snad právě proto NEmusí. Když je to sdílená paměť, tak se snad právě proto nemusí přesouvat, právě že se jen předá pointer, tak jsem to myslel.

Grunt avatar 20.8.2009 21:04 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Pozor, pokud není zavedený modul XShm(což už ve většině moderních distribucí je), tak se to musí kopírovat a nepředávají se žádné pointery. Předpokládám, že si to klient vyrenderuje do nějakého bufferu a pak se pointer popředává až grafice, která si to pomocí DMA natáhne do framebufferu.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 22:03 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Když je to sdílená paměť, tak se snad právě proto nemusí přesouvat, právě že se jen předá pointer, tak jsem to myslel.

Ale musi - na jedne strane se musi data presunout do sdilene pameti, na druhe strane presunout ze sdilene pameti. Nelze vzit jen tak pointer na nejakou pamet a tu nasdilet.

Grunt avatar 20.8.2009 22:07 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
BTW: Nešlo by ten buffer namapovat přímo do framebufferu?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
20.8.2009 22:15 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Myslim, ze standard pro XShm to podporuje jako volitenou variantu, ale x.org to nepodporuje. Hlavni problem je v tom, ze pamet muzes mapovat s granularitou stranek a pamet ve framebufferu je orientovana po radkach.

Ono to ale neni zas takova vyhra. Pristup do framebufferu pomoci memory read/write operaci je na velke casti grafickych karet celkem pomaly. Ve vetsine pripadu bude rychlejsi to nahrat do systemove pameti a pak to do graficke pameti prekopirovat bus master transferem.

Grunt avatar 20.8.2009 22:24 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ono to ale neni zas takova vyhra. Pristup do framebufferu pomoci memory read/write operaci je na velke casti grafickych karet celkem pomaly. Ve vetsine pripadu bude rychlejsi to nahrat do systemove pameti a pak to do graficke pameti prekopirovat bus master transferem.
Myslel jsem si to. Stejně je to vzhledem (k většinou zapnutému) double bufferingu na nic.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
27.8.2009 22:31 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Co takhle ještě lepší, namapovat ten buffer přímo do kompozitního bufferu. Efektivně využít kompozitního manažera. Osobně jsem doufal, že už to takle funguje. Že nepotřebeujete žádné XShm (mimochodem, kontroloval jsem log a 100% je zapntý? Mandriva 2009.1) ale klienti kreslí přímo do bufferu kompozitního manažeru a pak se celý buffer jednorázově překlopí do videoram.

No neříkal jsem, že kompozit je super věc :)  

28.8.2009 00:52 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Podle mě je to celé zbytečné dělat. Grafická karta je sice rychlá, ale co vy potřebujete je co nejmenší traffic do/z grafické karty. Pokud využijete grafickou kartu jen na kompozici (tedy uložíte tam zdrojové a cílové řádky, necháte provést kompozici a načtete zpět do RAM), tak to bude možná pomalejší, než na CPU (podle počtu těch věcí).

Říkám to z toho důvodu, že v SSE2/SSE4 to jde napsat opravdu celkem rychle (a například kompozice v Cairu i FOGu jde zrychlit asi o 25% - vyzkoušeno). Pak zjistíte, že kompozice pixelů je na celé grafické scéně to nejmenší. Naopak třeba implementace rasterizeru je oříšek. A otázka je, dokážete udělat rasterizaci na GK tak přesně jako je analytický rasterizer ve freetype? Pokud ne, bude muset existovat i SW backed, a bude se asi i hodně využívat:)
Grunt avatar 28.8.2009 01:01 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Podle mě je to celé zbytečné dělat. Grafická karta je sice rychlá, ale co vy potřebujete je co nejmenší traffic do/z grafické karty. Pokud využijete grafickou kartu jen na kompozici (tedy uložíte tam zdrojové a cílové řádky, necháte provést kompozici a načtete zpět do RAM), tak to bude možná pomalejší, než na CPU (podle počtu těch věcí).
Ano, zrovna toto by bylo téměř nemožné protože čtení z grafické RAM je snad nejpomalejší operace v celém počítači. Zrovna si to zkouším na vlastní kůži s vesou a vypnutým stínovým bufferem.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.8.2009 03:12 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> potřebujete je co nejmenší traffic do/z grafické karty

Přesně. Měl jsem za to, že když si připravým "celou scénu" v paměti (bufferu kompozitního managera) a pak ji jen překlopím do videoram, pak právě dosáhnu nejnižní traffic do karty. Možná je to jen moje naivní představa.

Z karty? Co je tohle za směr.

> využijete grafickou kartu jen na kompozici

To jsem nezamýšlel. To si asi nerozumíme. Jestli se špatně vyjadřuji, tak se omlouvám. Veškerý kompozit jsem zamýšlel dělat v běžné operační paměti.

Případné vylepšení - mohl bych překlopit do videoram jen změněné části obrazovky (XDamage?) a tím ještě snížil traffic.

27.8.2009 22:24 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

No jo, takhle ano. Mě šlo o to, že se nemusí přesouvat mezi X klientem a serverem. Mezi nimi se (snad) jen předá ten pointer. Že to klient nějak do shm dostat musí, to je přeci jasné. A že se to pak vybere a přesune do framebufferu/offcreen bufferu a zobrazí to je jasné taky.

21.8.2009 01:04 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Kdo kreslí primitivy. Jaký je řetězec událostí, aplikace chce nakreslit čáru - kdo a kde ji skutečně nakreslí (buffer? přímo do paměti videokarty?) jak se to bude lyšit když je apliakce v Qt, Gtk. S compozite, bez kompozitu, ...
V grafických knihovnách jsou často implementované operace s polygony, a takzvané fast-path funkce pro blitování obdélníků (stejná barva, obrázek, obrázek + maska, ...). V dnešní době se například i vykreslení kružnice řeší pomocí polygonů, takže efektivní rasterizer a dispatching grafické knihovny je podle mě jedena z nejdůležitějších věcí, co musí grafická knihovna mít.

Pokud umíte C++, a zajímá vás to do hloubky, tak doporučuji zkusit knihovnu antigrain. Tato knihovna hodně naučí o tom, jak celý proces funguje, co se musí s daty udělat, aby se například místo výplně kružnice vykreslil jen obrys (stroke), atd.

Zkusím rozebrat, co se stane při nakreslení čáry s využitím antialiasingu:
1. Zavolá se funkce dané knihovny, která má tu čáru vykreslit - line(x0,y0,x1,y1)
2. Vytvoří se grafická cesta, příkazy moveTo(x0, y0), lineTo(x1, y1)
3. Na tuto grafickou cestu se provede operace nazývaná jako stroke (obrys, nebo jak to přeložit). Výsledek je vytvoření uzavřeného polygonu, který je možné vyplnit - Máme polygon, to je věc, se kterou se dá dělat hodně.

Máme polygon, následující postup se už bude lišit v závislosti na knihovnách

4. Pokud máme analytický rasterizer (antigrain, Fog, freetype)
4a. Zavolá se rasterizer, ten vygeneruje tzv. seznam spanů, který se musí prohnat přes blitter
4b. Zavolá se blitter na všechny spany
4c. Hotovo

4. Pokud použijeme cairo a obyč obrázek (cairo nepoužívá analytický rasterizer, ale tesselator)
4a. Pomocí tesselatoru uděláme z našeho polygonu seznam lichoběžníků, které je potřeba vyplnit
4b. Alokuje se buffer (maska) o velikosti abs(x1-x0+1) x abs(y1-y0+1)
4c. Buffer se vyčistí (samé nuly)
4d. Zavolá se rasterizer (pixman) na každý lichoběžník
4e. Maska slouží pro provedení kompozitní operace s cílovým bufferem (ten, do kterého kreslíme)
4f. Hotovo

4. Pokud použijeme cairo s xlib surface (XRender)
4a. Pomocí tesselatoru uděláme z našeho polygonu seznam lichoběžníků, které je potřeba vyplnit
4b. Lichoběžníky pošleme XServeru
4c. XServer je zpracuje. Pokud je implementace XRenderu jen SW, použijí se stejné kroky jako nahoře.
4d. Hotovo

Je to jen obecný postup, a některé knihovny můžou mít speciální funkce pro případy, jako je čára, atd. Pokud máme rasterizer polygonu, můžeme dělat cokoliv (i elipsa se dá převést třeba na 200 vertexový polygon, který můžeme prohnat přes rasterizer). V mailing listu cairo jsem četl, že by chtěli analytický rasterizer (protože je rychlejší), ale nevím, jestli to bude hotové a nasazené ještě v našem století :) Podle mě platí, čím víc vrstev, tím méně výkonná knihovna.
27.8.2009 22:45 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Děkuji. To se blíží mým představám.

Ještě mi tam chybí ten nejjednodušší případ - obyčejná aplikace Gtk a Qt. Jak se vykreslí button na triviálním Gtk dialogu. Gtk standardně Cairo nepoužívá ani antigrani či Fog?

Trochu jste mě (a asi většinu čtenářů) zasypal pro mě neznámými termíny - span, blitter, tesselator - nejsem si teď jistý jetli jsou nutné pro pochopení "rozdělení kompetencí" mezi je nutné, o to mi šlo hlavně. Upozornit úzká místa systému, kde to vyžaduje přenosy velkých dat, atd. 

Pro porovnání, jak funguje Windows asi nevíte. Je to vůbec známé? není to zrovna open source.

28.8.2009 01:03 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ty pojmy jsou celkem známé v poč. grafice. Span je datová struktura obsahující pozici, průhlednost a délku. Blitter je funkce, která provede kompozici pixelů (třeba alpha blending). A tesselator převede polygon na trojúhelníky (openGL) / lichoběžníky (Cairo, XRender).

Ten příklad kreslení, to je těžké. Já třeba neznám přesně cestu, jak se to udělá, ale podle knihoven se to dá poskládat. Spíš bych se zaměřil na ty přenosy velkých dat. Co se mi osobně nelíbí je ten tesselator. Tesselator (důkazy a porovnání na netu, cairo mailing list něco obsahuje, ale i jinde, antigrain mailing list, atd) je pomalejší než analytický rasterizer. Pokud je XRender navržený tak, že je nejprve nutné použít tesselator, a až pak udělat požadavek XRenderu (CompositeTrapezoids, nebo tak nějak), tak máte zaručené, že pokud je XRender implementace pouze na straně SW, tak to bude pomalé (hodně pomalé). Dokonce o moc pomalejší než když si to client udělá sám. XRender je de fakto pixman na straně serveru.

No a jestli gtk cairo standardně používá nebo ne, to já nevím, nejsem glib/gtk fan:)

A jak to funguje ve windows? Antialiasing až po (včetně) WinXP je SW implementace. Jak to je ve WV nebo W7 netuším, ale GDI+, která se používá v XP je čistě SW knihovna, a před XP antialiasing GDI myslím vůbec neobsahovala (GDI+ je jiná knihovna)
21.8.2009 15:29 M. Lox | skóre: 12
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
… Síťový provoz, remote X, eeeh, zapomeňmě na to. Kolik lidí to vůbec používá? …
To se můžeme brzy dozvědět – navrhl jsem na toto téma anketu.
make menuconfig, not war!
20.8.2009 03:20 xyz
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Zajímavá shoda okolností. Nejspíš jde o jedno z bolestivých míst.

Jardík avatar 20.8.2009 12:50 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Ten článek mi připomněl, jak mi jednou při drag&drop v gimpu vytuhnul celý xserver a vzal s sebou i zbytek systému a nefungovalo absolutně nic, ani ssh nepomáhalo, musel jsem udělat reset mašiny a díky (ne)kvalitám ext3 filesystému to už vůbec nenaběhlo kvůli unknown filesystem. Někde v zákopech tu bude možná i můj zápisek.
Věřím v jednoho Boha.
20.8.2009 13:13 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
S tím článkem se nedá než souhlasit...
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
20.8.2009 18:12 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ten článek je plytká bída. Spadly mu Xka, pravděpodobně kvůli chybě v driveru (jakého? jaká karta?) a vzali sebou i nějaké další aplikace. Zbytek je rozčilené necílené oviňování všeho co ho při jeho chabé znalosti systému napadlo. V takovém emotivním stavu by člověk neměl psát, ani blog. Možná tak terapeuticky. Neuvádá žádné technické podrobnosti. Źádná snaha jít pod povrch.

Potřeboval se vykřičet z toho, že sebou Xka vzala i další aplikace. Budiž,  v tomto jednom bodě má jeho kritika základ. Taky nechápu proč v client server architektuře při pádu serveru musí ukončit činnost i klient, proč klient nemůže bez serveru existovat, to je jako by vám při výpadku web serveru okamžitě ukončil browser. Tohle je tak jediný postřeh co si člověk může z toho článku odnést.

Mimochodem, kdyby byl bug v kernelové části a vzal sebou i kernel, což je dost pravděpodobné, tak vám taky zatuhne taky celý systém a o neuložená data taky přijdete. To se vám může stát i ve Windows Vista a 7 stejně jako v Linuxu, tam i tam má display driver svoji kernelovou část. To si nějak autor při svém emotivním příspěvku neuvědomil.

21.8.2009 18:50 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Docela tě vystihl tímhle odstavečkem:
And then we get the finger-pointing. I'm sure the usual suspects are already busy churning out comments about how this is the fault of the driver, VLC, myself, the 30 Rock video, planetary alignment, anal probes, whatever. And all of you will miss the point completely: I don't care where the problem lies. Bugs happen. Crashes happen. That's a fact of life, and something that you have to accept when using software. However, under no circumstances should resizing a video window result in a complete system failure!
Uděláš lépe, když se raději skutečně podíváš na dokumentaci k windows vista/7 grapchis stack + wddm. Vsadím se, že doteď jsi to ani nepřečet.
Ten model os MS je prostě mnohem líp navrženej než X.

Já nevím, proč musej někteří lidi fanaticky bránit Xka jen proto, že to je "ten náš" grafickej server. A že to je chyba driveru atd. atd. To je jedno kde je chyba. Podstatný je, že jedna blbá chyba v jednom blbým driveru nakope X do řiti i s celým UI a aplikacemi. To se prostě nemá stát a je potřeba na to pamatovat při návrhu architektury.

Pokud budeš rozlišovat na "ty hodný" (X, SSH, RTFM, ...) a "ty zlý" (Windows, WDDM, user-friendliness), tak se nikam nepohnem. Tohle není Pán Prstenů.
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
27.8.2009 22:18 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery Windows

To reagujete na mě? Jste si jistý že nereagujete na Grunta? Četl jste co jsem psal? nebo je to taková náhodně

Ne článek jsem opravdu nečetl, samozřejmě, stejně jako jsem nečetl Xlib API a XRender dokumentaci (jako už tu navrhovali jiní) nikde jsem nenaznačil, že jsem v oblasti odborníkem.

Z toho odkazovaného obrazku není nijak zjevné jesti a v čem je lepší než Xorg model, k tomu chybí právě ten srovnávací článek po kterém volám. Chybí kvalitní laicky přístupném kratší články, abych si zachoval základní přehled v oblasti.

Já nehodlám programovat vnitřnosti ani v Xorg ani WDDM. Když chci získat základní přehled o astronomii, sáhnu po "Okna vesmíru dokořán" od Grygara a ne po skriptech postgraduálního studia astronomie na FFUK ;-)

Mimochodem, vy o této problematice něco víte? Nebo je zvládáte jen vkládat nic nevysvětlující odkazy do diskuse?

Hlavně by mě zajímala implementace DM ve Windows XP, měly compozitního manažera nebo ne? Jetli uměly průhlednost tak musely. Byl zapnutý defaultně? Šlapalo jim to pěkně na všech konfiguracích a kartách co jsem viděl, jestli se dobře pamatuji, tak i ve VESA režimu, bez hw, akcelerace. U nativních aplikací jste neviděli žádné překreslování okna, žádné artefakty, prostě "rock solid", to se musí nechat. Jak toho bylo dosaženo? Srovanat s Xorg. Proč to Xorg nezvládá. 

> Ten model os MS je prostě mnohem líp navrženej než X.

To je klidně možné, já takovou možnost v blogu naznačuji.

Nejvíc ale dělá kvalita implementace. Ta byla u Vist bída (viz přiložený obrázek) a jak tady __dark__ tvrdí tak ani tak tak Xorg implementace má také svoje nevábná místa a zadní dvorečky. Já byl spokojený s Windows XP,

> Já nevím, proč musej někteří lidi fanaticky bránit Xka jen proto, že to je "ten náš" grafickej server.

Zkuste tuhle repliku použít pod příspěvky těch, kteří to tvrdí. Asi jste si toho nevšiml (článek, reakce), ale já mezi ně nepatřím.

> Pokud budeš rozlišovat na "ty hodný" (X, SSH, RTFM, ...) a "ty zlý" (Windows, WDDM, user-friendliness)

To asi zase není reakce na mě, co? Zkus Grunta ;-)

Já jsem ten poslední co propaguje černobílé vidění, od IT až po politiku a historii.

Jestli jsem něco kritizoval, tak to byla kvalita odkazovaného článku. Ten je ubohost, za tím si stojím. Padla tam jediná kloudná výtka - že Xorg klienti nepřežijí restart serveru Neříká to tam přímo, na to jsou jeho znalosti Xorg nedostatečné. Ta výtka je jinak OK, měl bych

> However, under no circumstances should resizing a video window result in a complete system failure!

Jak napovídá váš odkaz na architekturu WDDM, pak se to může stát i ve Windows Vista, přesně jak jsem si myslel. Alespoň se ten odkazovaný graf k něčemu hodil. Můžeme jen spekulovat o tom, že se tak na jednom či jiném OS může stát pravděpodobněji.

Věřím, že jde napsat kvalitní článek vysvětlující v čem je lepší Windows model (implementace) od Xorg model, implementace. Otázky které by tam měly být řešené, jsem naznačil výše. Zatím na takový jen čekám.

Grunt avatar 27.8.2009 22:36 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery Windows
To asi zase není reakce na mě, co? Zkus Grunta
Co furt do toho taháte toho zelenáče s křivou hubou? Já mám snad černobílé vidění? Já snad hraju "Pána prstenů" a značkuju si dobro a zlo? Nenechte se mýlit. Já s Windowsy nemám nic společného. Mně je to naprosto egal.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
27.8.2009 23:02 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery Windows
Mimochodem, vy o této problematice něco víte? Nebo je zvládáte jen vkládat nic nevysvětlující odkazy do diskuse?
Něco trochu, ne nějak moc, rád bych věděl víc. Tedy rozhodně nejsem natolik erudovaný, abych vytvořil takový článek, jaký si přeješ.
Hlavně by mě zajímala implementace DM ve Windows XP, měly compozitního manažera nebo ne?
Ne, neměly.
Jetli uměly průhlednost tak musely.
Ne, nemusely a neměly. Průhlednost se prostě spočítala přes CPU. O všechno se staral GDI - graphics stack pracující s bitmapami. Žádná akcelerace tam nebyla. Pokud nějaký program využíval Direct3D nebo OpenGL, tak si prostě vytvořil plátno, které GDI nechalo bejt napokoji a do dané obasti kreslila grafárna.

Modelem XPDM se ale nemá moc cenu se zabývat, je technologicky pasé. Inspirace GDI/XPDM by neřešila problémy X na linuxu.
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
28.8.2009 03:43 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery Windows

> Průhlednost se prostě spočítala přes CPU.

A to vylučuje kompozit? Softwarový kompozit je stále kompozit. U kompozitu je základní vlastnost, že se vykresluje do speciálního off screen bufferu místo přímo na obrazovku. Kompozitní manager != OpenGL nebo DirectX; může a nemusí jich používat. U kwin je hw akcelerace kompozitu volitelná. Xcompmgr, nejstarší implementace KM pro Xorg, je čistě sw.

Grunt avatar 28.8.2009 01:10 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery Windows
Hlavně by mě zajímala implementace DM ve Windows XP, měly compozitního manažera nebo ne? Jetli uměly průhlednost tak musely. Byl zapnutý defaultně? Šlapalo jim to pěkně na všech konfiguracích a kartách co jsem viděl, jestli se dobře pamatuji, tak i ve VESA režimu, bez hw, akcelerace. U nativních aplikací jste neviděli žádné překreslování okna, žádné artefakty, prostě "rock solid", to se musí nechat. Jak toho bylo dosaženo? Srovanat s Xorg. Proč to Xorg nezvládá. 
Můžu se zeptat o čem je řeč? Momentálně běžím na F12, 800Mhz procesor a rozlišení 1440x900 s vesa driverem a vypnutým stínovým bufferem(Xorg to renderuje přímo framebufferu) a pokud nepočítám kopírování z něj a SW cursor, tak v tom také moc problém nevidím. Rozhodně ne žádné artefakty a další popisované věci. A je to sice k údivu ale zrovna s tou změnou velikosti oken jsou problémy nejmenší(skoro jako s HW akcelerací). A nebo to mám snad ještě zpomalit o pár vrstev v podobě fbdev driveru uvesafb modulu aby to bylo srovnatelné?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.8.2009 03:37 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery Windows

Viz obrázek pod blogem, ten pravý. Radeon 7500, driver radeon, vypnutý kopompozit (vypnutý compiz, kwin3) vyzkoušeno se řadou distribucí, pozoruji to na všech počítačích s linuxem, ati i nvidia, na těch rychlejších ne tak patrně. Dělá to i v gnome, fvwm (výrazně méně ale také).

Mám podobných screenshotů celou řadu, plus extra řadu artefaktů v OOo, tam jsou bohužel některé permanentní, OOo překreslováním canvasu šetří.

Zajímavé je, že nikdy, nikdy, to nepozoruji na dekoracích oken, jakkoliv moc jich tam naskládám.

Jakmile zapnu kompozit, vše mizí a desktop je "rock solid". Bohužel to má (mělo) zase svoje jiné vrtochy.

Mám o tom polo připravený zápisek už asi dva roky :-)

Já vím, není to tragédie, s takovýmhle desktopem se dá efektivně pracovat a já to tak pár let dělám, ale prostě to nevypadá tak profesionálně jako u XP. Drobnsot, možná namítnete, ale je to viditelná drobnost, je to něco jako když máte špinavou výlohu v krámě, funkčně to krámu neubere, ale zákazníky to trochu odrazuje. 

Vesu jsem už dlouho nezkoušel. Asi to ani nemá cenu, pak chybí Xv a akcelerované 3D (a to nejsou jen gamesky).

Grunt avatar 28.8.2009 12:43 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery Windows
Viz obrázek pod blogem, ten pravý. Radeon 7500, driver radeon, vypnutý kopompozit (vypnutý compiz, kwin3) vyzkoušeno se řadou distribucí, pozoruji to na všech počítačích s linuxem, ati i nvidia, na těch rychlejších ne tak patrně. Dělá to i v gnome, fvwm (výrazně méně ale také).
Ano, podobný efektů jsem byl též svědkem. A shodou okolností to bylo v dobách kdy jsem si vlastnoručně kompiloval Qt3. Nemám si o tom začít připravovat zápisek, že?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Jardík avatar 20.8.2009 12:42 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Moderní frameworky si renderují text sami, s použitím FreeType2 knihovny a XRender extension. Díky tomu máme kvalitní anti-aliasing. Nestálo by za to takové „mrtvé“ části X11 zrevidovat a vyškrtat?
Ne, neškrtat to, ale řešit to pořádným/novým API pro fonty (freetype api je děs, je skoro nutné do toho tahat fontconfig, xft a další blbiny, co zpomalujou).

Stejně bych řešil GUI, funkce v X jsou příliš "jednoduché", nějaký widgety by se tam hodily v základu, aby se to nemuselo 3x obalovat (a s každým obalem tu máme hnusný overhead), než z toho něco vykoukne (X->glib+gdk->gtk).

Xgl byl dobrý, pamatuji, jak tam composite s nvidií bylo krásně plynulé, nic se nesekalo. Jenže AIGLX to celý podělalo, od tý doby je to na tý nvidii znatelně pomalejší, na intelu je to pomalé taky (tam jsem ale Xgl nezkoušel, už bylo mrtvý).
Věřím v jednoho Boha.
20.8.2009 19:10 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

No když se to nepoužívá tak snad škrtnout ne? vy víte o nějaké nějaké aplikaci která je skutečně používá? Tak prý snad xterm, bez toho by jsme se snad obešli. Konzolových klientů je tu hned několik. Absolutně netuším, jak by změna FreeType API změnila něco ve vztahu k Xkám. Ty jí přímo nijak nepoužívají. Xft nemusíte používat, řada distribucí ho neobsahuje vůbec. Fonconfig teoreticky taky ne, pak ale uživatel přijde o možnost si nadefinovat zobrazení fontů (anialiasing, ..) pochybuji, že by jste našel defaultní hodnoty vyhovující všem. Fonconfig není o moc víc než centrálně v paměti udržovaná konfigurace fontů, naparsovaný konfigurák, chcete li.

Widgety přímo v X. Ha ha, takhle spečený to nemá ani Microsoft :-) On i takhle je Xorg moloch sám o sobě a ještě do něj přidávat, to snad ne. Xorg potřebuje dietu. Xorg by se nemělo za mák starat o obsah okna, co si tam aplikace kreslí nebo ne, jen se starat na jaké pozici to bude, aby to nepřeteklo rozměry okna (tak nějak doufám moderní frameworky, widgety, canvasy, fungují a fungovat mají) a nějak efektivně se s vykreslováním obsahu dohodnout na synchronizaci vykreslování (a tady to drhne, hlavně u resize, u statického okna to není problém, tam není se moc o čem domlouvat).

V Xgl jste si zase nespustil jinou openGL aplikaci, hru, GoogleEarth, to je dost závažná vada na kráse.

stativ avatar 20.8.2009 12:45 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Let's Talk About X, Baby. Docela zajímavý.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
20.8.2009 18:52 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Co je tam zajímavého? Je tam odkaz na http://www.osnews.com/story/21999/Editorial_X_Could_Learn_a_Lot_from_Vista_Windows_7 - což je mimořádně slabý článek jak rozebírám o něco víš. A pak odkaz na mp3. Jako tam se baví o tom článku? To je jen mrhání časem, to snad nemá cenu poslouchat.

 

stativ avatar 20.8.2009 18:58 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Mně to přijde docela zajímavý nápad. Viz mikrokernely. Možnost něco okamžitě resetovat po pádu a mít možnost tak ještě něco uložit je IMO výhodné.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
20.8.2009 19:15 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

?? Poslal jste mi správný link? mikrokernely? Mám si přeci jen poslechnout tu mp3, je to vní? V tom slaboduchém odkazované článku nic takového není.

stativ avatar 21.8.2009 09:26 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Jak to? Spousta mikrokernelů funguje podobně, nebo se o to alespoň snaží. Myslím, že třeba takový Minix a QNX umí znovu spustit většinu (samozřejmě pokud spadne samotné jádro, tak je to k ničemu) běžících služeb okamžitě po pádu tak, že nikdo nic nepozná. Zajímavý byl taky EROS, ale IMO jeho řešení je na nic z pohledu plýtvání zdroji.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
Jardík avatar 20.8.2009 12:56 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
BTW tohle dokazuje debilitu vymlouvání se na nahrávací SW. V prvním případě bez composite - docela to ujde, i když ve Windows je to plynulejší. V druhém případě s composite - vidíte tu nehoráznou trhanost (ať už u sync či async okna)? To není nahrávacím SW, to je tím hackoidním composite, který je tak kreténcky implementovaný, že všechno co děláte se 10x zpomalí.
Věřím v jednoho Boha.
20.8.2009 18:43 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Nedokazuje to ve věci vhodnosti-nevhodnosti nahrávacího SW absolutně nic. Jak jste na to přišel? Vždycky můžete tvrdit, že použitý nahrávací SW určitý způsob práce volání X z aplikace znevýhodňuje, není to jen otázka kompozitu. Nemáte záruku, že takto nahraný screencast je to co opravdu viděl uživatel.

K nezávislému posouzení potřebujete měření zařízením které nijak neinterferuje s pozorovaným subjektem. Jedině nezávislá kamera s dostatečným fps je vhodný a dobře obhajitelný který se dostanete co nejblíž k tomu jak to opravdu vidí uživatel.

Pod KWin nic takového nepozoruji, Compizu (z něho je ten screencast) už jsem dlouho nezkoušel ale co se pamatuji, s obovou obsahu okna byly problémy - scrollování ve Firefoxu, animace v aplikaci, Flash, to samé u předchůdců Compizu a KWin - viz můj starší blog - http://www.abclinuxu.cz/blog/Espblog/2006/11/kompozitni-manazery-compiz-a-beryl-nejsou-jedini.

"hackoidním composite, který je tak kreténcky implementovaný" - kterou implementaci máte na mysli? jen pro Linux existují tak minimálně 4, z čehož 2 umožňují hw akceleraci.

Jinak základní compozitní manager (vykreslování do offscreen bitmapy) už museli mít nejméně Windows 2000/XP, ale pravděpodobněji už i 95 a 98. Musí se uznat, že ho měly vychytaný, a šlapal i bez hw akcelerace, což se o KWinu ani Compizu tak docela říci nedá.

Jardík avatar 20.8.2009 22:18 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Nedokazuje to ve věci vhodnosti-nevhodnosti nahrávacího SW absolutně nic.
Ano, k malému zpomalení možná dojde, ale pokud srovnáte rychlost těch oken na těch dvou videích (s velkou pravděpodobností nahrávaných stejným SW na stejném počítači i systému), tak si nelze nevšimnout totální pomalosti oken se zapnutým composite - kdyby v druhém případě nebylo zpomalení tak obrovské, mohlo by to možná být tím SW, ale to není a dokazuje to totáln=i pomalost composite.
Věřím v jednoho Boha.
27.8.2009 22:57 Espinosa | skóre: 24 | blog: Espblog | London
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

 

Ano, k malému zpomalení možná dojde, ale pokud srovnáte rychlost těch oken na těch dvou videích (s velkou pravděpodobností nahrávaných stejným SW na stejném počítači i systému), tak si nelze nevšimnout totální pomalosti oken se zapnutým composite - kdyby v druhém případě nebylo zpomalení tak obrovské, mohlo by to možná být tím SW, ale to není a dokazuje to totáln=i pomalost composite.

"Malé zpomalení", "možná dojde" podle čeho víte že právě malé a usuzujete na frekvenci? To jen hádáte. Nepodložená doměnka. Příliš dobře napadnutelné. Záznam z DV kamery už mnohem mnohem hůř, to už musíte vzít z jiného konce - co je to za mizernou distribuci, jak si rozvoral xorg.cong a tak ;-) Zpochybnitelné je všechno, jde o tu míru, a argumentace screencastem stojí na slabých nohou.

 

22.8.2009 16:14 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

Ha, ted uz me doslo, proc Espinoza (a nekteri dalsi) mel takove obavy z 'asynchronniho' protokolu - byl zmaten tim odkazovanym clankem (zminujicim _NET_WM_SYNC_REQUEST). Tam ale jde o asynchronnost uplne jineho druhu, nez asynchronnost protokolu.

Problem s resizem je v tom, ze o okraj okna a o obsah okna se staraji odlisne procesy - obsah okna ridi aplikace a okraj (ramecek) okna ridi window manager. Normalne tyto dva procesy navzajem nejsou synchronizovane, a tak prekrereslovani obsahu je ve skluzu za prekreslovanim okraje.  To je ale vec, ktera vubec nesouvisi s tim, ze X protokol je asynchronni. I kdyby X protokol byl synchronni, tak tyto dve cinnosti nemusi byt navzajem synchronizovane (nebot se jedna o odlisne klienty), naopak, i s asynchronnim protokolem je mozne tyto cinnosti synchronizovat (coz dela ten _NET_WM_SYNC_REQUEST).

A jak odkazovany clanek zminuje (a ja jsem take zminoval), takovy druh synchronizace sice zajisti, ze okraj a obsah si budou odpovidat, ale krom toho to muze zpusobit trhanejsi odezvu na resizing (protoze prekreslovani okraje bude brzdeno tim prekreslovanim obsahu).

Jardík avatar 23.8.2009 00:42 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
protoze prekreslovani okraje bude brzdeno tim prekreslovanim obsahu
To platí ve všech window managerech kromě kwinu, kde se čeká na kwin :-)
Věřím v jednoho Boha.
23.8.2009 15:29 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery
Tak jsem se podival na to, co dela ten _NET_WM_SYNC_REQUEST, a vypada to, ze to dela neco malicko jineho nez popisujete :-) Podle specifikace by to melo delat to, ze pri resize okna musi dat aplikace vedet window manageru, ze je vse hotovo a do te doby nesmi window manager poslat dalsi configure event. Laicky receno, window manager nezmeni velikost okna do te doby, nez se aplikace neprekreslila z predchozi zmene velikosti.

Tento problem lze ale celkem dobre vychytat tak, ze pri zpracovani udalosti se zpracuje jen posledni XConfigureRequest.
24.8.2009 21:10 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Zamyšlení nad stavem linuxového GUI - Xorg, X11, Drivery

> Podle specifikace by to melo delat to, ze pri resize okna musi dat aplikace vedet window manageru, ze je vse hotovo a do te doby nesmi window manager poslat dalsi configure event. Laicky receno, window manager nezmeni velikost okna do te doby, nez se aplikace neprekreslila z predchozi zmene velikosti.

Tak jsem to snad popsal, ne?

> Tento problem lze ale celkem dobre vychytat tak, ze pri zpracovani udalosti se zpracuje jen posledni XConfigureRequest.

To se standardne dela a ten problem to neresi.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.