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

[Jan Drábek]

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).

[Roger]

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).

[VRtulnikk]

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.

[goo_one]

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

[User682]

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

[Roger]

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

[thingie]

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.

[User682]

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.

[User682]

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

[Roger]

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

[Zdenek]

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.

[J. M.]

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]

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.

[kralyk z abclinuxu]

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...)

[kralyk z abclinuxu]

*vykreslování a *freedesktop

[thingie]

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.

[Ondrej 'SanTiago' Zajicek]

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]

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.

[Ondrej 'SanTiago' Zajicek]

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

[Marex]

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

[Ivan]

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).

 

[Ondrej 'SanTiago' Zajicek]

> 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)
  

[Ivan]

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.

 

[Ondrej 'SanTiago' Zajicek]

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

[Deleted [8409]]

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í).

[petr_p]

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]

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).

[J. M.]

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.

[R]

GTK s jeho ultrapomalostou to cele zabije :D

[Murry]

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

[J. M.]

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/

[Murry]

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

[stativ]

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.

[J. M.]

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]

Bezvadné.

[Grunt]

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.

[thingie]

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.

[Grunt]

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.

[thingie]

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ě.

[Ondrej 'SanTiago' Zajicek]

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]

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.

[Grunt]

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.

[Ondrej 'SanTiago' Zajicek]

> 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]

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.

[Ondrej 'SanTiago' Zajicek]

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.

[J. M.]

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.

[Ondrej 'SanTiago' Zajicek]

> 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.

 

[J. M.]

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]

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?

[Grunt]

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).

[Ondrej 'SanTiago' Zajicek]

> 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]

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í.

[Ondrej 'SanTiago' Zajicek]

> 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.

[kralyk z abclinuxu]

composite extension sama o sobe je pekna obludnost, ktera nemela nikdy vzniknout

A to proč?

[Ondrej 'SanTiago' Zajicek]

Nema to smysluplne pouziti a akorat to srada pamet.

[mirec]

Asi tak ... reálne využitie žiadne, hlavne, že sa na to zameriavajú ako keby to bola najdôležitejšia súčasť X.

[kralyk z abclinuxu]

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í".

[mirec]

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"?

[kralyk z abclinuxu]

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.

[Ladicek]

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?

[mirec]

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.

[kralyk z abclinuxu]

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...

[mirec]

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.

[kralyk z abclinuxu]

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.

[Nicky726]

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.

[Marek Bernát]

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é.

[thingie]

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…

[mirec]

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).

[thingie]

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.

[petr_p]

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]

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.

[Ondrej 'SanTiago' Zajicek]

> 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.

[Espinosa]

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.

[Ondrej 'SanTiago' Zajicek]

> 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]

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.

[Ondrej 'SanTiago' Zajicek]

> 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]

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.

[Deleted [8409]]

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]

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?

[Espinosa]

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.

[Ondrej 'SanTiago' Zajicek]

> 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ý]

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...

[misch]

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]

Skôr je to tým, že ľudia tam chcú ukázať aj wallpaper.

[Jakub Lucký]

přesně tak... Ale myslíte si, že geekové používají na práci titěrná okýnka?

[Jakub Lucký]

druhá věta měla být reakce ještě o úroveň výš...

[Ondrej 'SanTiago' Zajicek]

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).

[pht]

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.

[Michal Fecko]

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...

[kralyk z abclinuxu]

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...

[pht]

Já jsem pro nové věci, ale implementované poněkud méně drastickým a chaotickým způsobem.

[kralyk z abclinuxu]

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".

[pht]

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.

[Mark]

 

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.

 

[petr_p]

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.

[Mrkva]

Příloha:

• ukazka1.jpg (150064 bytů)

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 :)

[kralyk z abclinuxu]

+1

[Shadow]

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).

[Nicky726]

Hezké!

[Jakub Lucký]

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

[Deleted [8409]]

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...:)

[Ondrej 'SanTiago' Zajicek]

> 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).

[Deleted [8409]]

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.

[Ondrej 'SanTiago' Zajicek]

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.

[Deleted [8409]]

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

[Ondrej 'SanTiago' Zajicek]

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.

[Deleted [8409]]

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á).

[Ondrej 'SanTiago' Zajicek]

> 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.

[Deleted [8409]]

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]

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.

[Ondrej 'SanTiago' Zajicek]

> 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.

[Deleted [8409]]

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:)

[Ondrej 'SanTiago' Zajicek]

> 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.

[petr_p]

K čemu máme stovky megabajtů paměti na grafických kartách?

[Jardík]

Aby 32bit šmejďárnám zabíraly stovky megabajtů v paměti a měli tak "méně" adresovatelného prostoru.

[Ondrej 'SanTiago' Zajicek]

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

[J. M.]

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.

[J. M.]

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é.

[kralyk z abclinuxu]

Pořád to samozřejmě nemá na Windows

Že vy toho vo těch windows nabásníte... viz video z mejch win xp.

[xyz]

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.

[J. M.]

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.

[J. M.]

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.

[Michal Kašpar]

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ý?

[J. M.]

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).

[Deleted [8409]]

Když si otevřu web, který má vertikální obsah na statisíce pixelů, tak bude pomalým resize trpěk každý browser.

[Michal Kašpar]

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.

[Deleted [8409]]

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.

[Michal Kašpar]

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.

[J. M.]

Nautilus má primitivní GUI. Na čemkoli složitějším je rozdíl víc než markantní.

[kralyk z abclinuxu]

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)

[mirec]

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.

[J. M.]

No Windows XP z roku 2001 samozřejmě ne. Ani Linux to v roce 2001 neměl.

[mirec]

Tak prečo tu niektorí tvrdia, že windows má compositing už niekedy od windows 98?

[J. M.]

To tu nikdo netvrdí. Pleteš si úplně nesouvisející věci.

[Espinosa]

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.

[J. M.]

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.

[J. M.]

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]

Lze to nějak nastavit jako výchozí?

[mirec]

Pri kompilácii. U gentoo užívateľov USE flag raster.

[J. M.]

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]

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.

[thingie]

Copak raster. Ale opengl!

[mirec]

OpenGL je ešte pomalšie než native ... O stabilite radšej pomlčím (intel).

[thingie]

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.

[J. M.]

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]

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... :-/

[kralyk z abclinuxu]

den práce tebe nebo toho stroje?

[Nicky726]

Stroje, KDEmod má docela dobře vymakaný buildsystém, takže stačí napsat jeden příkaz a odentrovat.

[Deleted [8409]]

Nerozbité by mělo být akcelerované, ale nevím, o kolik by mělo to akcelerované být rychlejší.

[Deleted [8409]]

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.

[Ondrej 'SanTiago' Zajicek]

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.

[Deleted [8409]]

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

[Ondrej 'SanTiago' Zajicek]

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

[Deleted [8409]]

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í.

[Ondrej 'SanTiago' Zajicek]

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

 

[Deleted [8409]]

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.

[Ondrej 'SanTiago' Zajicek]

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).

[Deleted [8409]]

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).

[Ondrej 'SanTiago' Zajicek]

> 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).

[Deleted [8409]]

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.

[Ondrej 'SanTiago' Zajicek]

> 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.

[Deleted [8409]]

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.

[Ondrej 'SanTiago' Zajicek]

> 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.

[Espinosa]

 

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 :)

[Ondrej 'SanTiago' Zajicek]

> Č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.

[Espinosa]

 

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]

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!

[thingie]

Bylo by vhodné podotknout, že NX není samostatný nový protokol, který by s X neměl nic společného.

[Ondrej 'SanTiago' Zajicek]

> 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.

[miso]

 

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 ).

[Grunt]

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.

[Espinosa]

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]

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ě)?

[Espinosa]

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]

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.

[Grunt]

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?

[Grunt]

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.

[Ondrej 'SanTiago' Zajicek]

> 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?

[Espinosa]

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]

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.

[Grunt]

Kromě podpory síťové vrstvy v X.

Dle mého názoru, by naopak synchronizace síťovému provozu moc ulehčila.

[thingie]

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.

[Grunt]

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)

[Espinosa]

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]

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.

[Espinosa]

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]

Ještě jednou ne, ne, ne! Ani omylem. Běžte (si) do…Windows.

[Espinosa]

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]

"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?

[thingie]

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.

[Grunt]

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.

[Espinosa]

> 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]

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.

[Ondrej 'SanTiago' Zajicek]

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

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

[Grunt]

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.

[Espinosa]

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]

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.

[Ondrej 'SanTiago' Zajicek]

> 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]

BTW: Nešlo by ten buffer namapovat přímo do framebufferu?

[Ondrej 'SanTiago' Zajicek]

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]

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.

[Espinosa]

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 :)  

[Deleted [8409]]

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]

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.

[Espinosa]

> 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.

[Espinosa]

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.

[Deleted [8409]]

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.

[Espinosa]

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.

[Deleted [8409]]

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)

[M. Lox]

… 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.

[xyz]

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

[Jardík]

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.

[kralyk z abclinuxu]

S tím článkem se nedá než souhlasit...

[Espinosa]

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.

[kralyk z abclinuxu]

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ů.

[Espinosa]

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]

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.

[kralyk z abclinuxu]

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.

[Espinosa]

> 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]

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é?

[Espinosa]

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]

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?

[Jardík]

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ý).

[Espinosa]

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]

Let's Talk About X, Baby. Docela zajímavý.

[Espinosa]

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]

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é.

[Espinosa]

?? 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]

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.

[Jardík]

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í.

[Espinosa]

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]

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.

[Espinosa]

 

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.

 

[Ondrej 'SanTiago' Zajicek]

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]

protoze prekreslovani okraje bude brzdeno tim prekreslovanim obsahu

To platí ve všech window managerech kromě kwinu, kde se čeká na kwin

[Deleted [8409]]

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.

[Ondrej 'SanTiago' Zajicek]

> 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.