Portál AbcLinuxu, 25. dubna 2024 02:41
19.8.2009 17:28
Jan Drábek | skóre: 41
| blog: Tartar
| Brno
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).
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).
Nema Swing naaahodou lehce problemy s vykreslovanim? Treba s (ne)pouzivam XRender a sw rasterizaci?
19.8.2009 18:37
thingie | skóre: 8
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.
toto nevim. Kdytak pohledejte sun-i bugparadu. Je tam toho mraky.
19.8.2009 19:15
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
19.8.2009 18:22
thingie | skóre: 8
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.
19.8.2009 19:18
thingie | skóre: 8
Neexistuje. Ale dokud ten Intel ovladac bude takto rozbity, tak jsem rad za ty rychle terminaly.
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).
> 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)
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.
Myslim, ze ve Windows se antialiasing pouziva. Akorat tam asi nemaji tak rozbite ovladace.
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).
Nevis o tom vice informaci?Je to uz sputitelny (nerikam ze pouzitelny)? Toto by me zajimalo.
tedka jsem nasel na netu nejaky info, dokonce repozity, ale tam je posledni commit 29.5. ale treba byla presunuta, nevim.
20.8.2009 09:43
stativ | skóre: 54
| blog: SlaNé roury
20.8.2009 10:06
stativ | skóre: 54
| blog: SlaNé roury
19.8.2009 19:06
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
19.8.2009 19:16
thingie | skóre: 8
19.8.2009 19:19
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
19.8.2009 19:22
thingie | skóre: 8
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.
19.8.2009 19:32
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
19.8.2009 19:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
> 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).
19.8.2009 19:25
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
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.
> 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.
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 wmTvoje 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 nicemuNení. 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.
19.8.2009 21:14
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
19.8.2009 21:16
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
> 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).
19.8.2009 21:58
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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í.
> 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.
composite extension sama o sobe je pekna obludnost, ktera nemela nikdy vzniknoutA to proč?
Nema to smysluplne pouziti a akorat to srada pamet.
20.8.2009 09:07
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 12:46
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 13:48
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
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.
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á.
20.8.2009 18:23
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
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.
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í.
22.8.2009 13:15
Nicky726 | skóre: 56
| blog: Nicky726
22.8.2009 15:33
Marek Bernát | skóre: 17
| blog: Arcadia
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é.
20.8.2009 13:18
thingie | skóre: 8
20.8.2009 13:49
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 14:01
thingie | skóre: 8
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á.
20.8.2009 14:04
thingie | skóre: 8
> 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.
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.
> 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.
20.8.2009 20:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
> 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).
21.8.2009 06:25
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 13:35
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
> 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.
19.8.2009 22:10
Jakub Lucký | skóre: 40
| Praha
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...
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
20.8.2009 09:08
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 10:08
Jakub Lucký | skóre: 40
| Praha
20.8.2009 10:20
Jakub Lucký | skóre: 40
| Praha
Co se tyce grafickych driveru u Intelu, to je celkem tragedie. Prijde me, ze napsat driver, ktery plne akceleruje tech par zakladnich operaci (copy a fill rectangle, transfery mezi operacni a grafickou pameti, zakladni obdelnikove render operace a renderovani glyphu z glyphsetu), ktere jsou treba pro 90% desktopu, by byla zalezitost tak na tyden (myslim tedy jen renderovaci casti, nikoliv inicializaci a modesetting). Misto toho se pise GEM, graficky memory manager, ktery je pro normalni desktopove nasazeni uplne zbytecny (i kdyz je pravda, ze z dlouhodobeho hlediska je to rozhodne dobry koncept).
19.8.2009 20:28
Michal Fecko | skóre: 31
| blog: Poznámkový blog
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.
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 :)
19.8.2009 22:55
Shadow | skóre: 25
| blog: Brainstorm
19.8.2009 21:39
Nicky726 | skóre: 56
| blog: Nicky726
19.8.2009 22:17
Jakub Lucký | skóre: 40
| Praha
> 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).
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.
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.
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á).
> Vektorová grafika se bude používat čím dál víc, a je jen na knihovnách, jak efektivně ji budou implementovat (cairo v tomto případě zatím selhává).
Jiste, ale malokdy je vhodne ji renderovat na serveru pri kazdem expose eventu. Pokud se nejedna o skutecnou grafiku (napr. vektorovy graficky program), ale jen o graficke prvky GUI (fonty, ikonky, nebo i onen zminovane kolecko v radio buttonu), u kterych se ocekava, ze budou pouzity mnohokrat ve stejne velikosti, tak je rozumne, i kdyz jsou jejich zdroje vektorove, je proste jednou predrenderovat do pixmap a pak vykreslovat ty pixmapy. A v takovem pripade je vcelku jedno, jak se to renderovani provede.
Skutecne vektorove graficke API (jako ty lichobezniky v XRenderu) je potreba az na renderovani takovych vektorovych obrazku, u kterych vyse zmineny pristup neni vhodny.
20.8.2009 23:15
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
> 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.
> Takto by XServer mohl rozhodnout, pro které aplikace backbuffer alokovat.
To v podstate dela kompozitni manager pomoci composite extension, pokud se pouziva.
> Qt4 aplikace myslím double-buffering používají jako default, a zachvilku začnou určitě i gtk,
GTK pouziva double buffer automaticky uz od verze 2.0. Ale pouzivani double bufferu obecne pamet nezere - pri expose eventu se buffer alokuje, do nej se kresli, pak se to jako celek prekresli do onscreen a vzapeti se buffer zahodi.
Ale doube buffer je n eco jineho nez backing store, o kterem se tu spis mluvi.
BTW, jak jsem se zminoval o tech popupech, tak tam se nejedna o backing store (ukladani obsahu okna, kdyz ho cast neni videt), ale o ukladani obsahu pod danym oknem (save under flag).
Je otazka, zda by neslo implementaovat 'pekne' posouvani oken (bez expose eventu pro docasne prekrytak okna) tak, ze by WM posouvanemu oknu docasne nahodil save under flag.
21.8.2009 11:45
Jardík | skóre: 40
| blog: jarda_bloguje
No nekolik mych poslednich pocitacu (vcetne soucasneho) ma integrovanou grafiku s 32 MB RAM.
rozbité znamená fallback do pixmanuA nerozbité?
u mě je v Qt rasterengine rychlejší než x11Hergot, 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.
Pořád to samozřejmě nemá na WindowsŽe vy toho vo těch windows nabásníte... viz video z mejch win xp.
Př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.
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čemNe, kompresí videa to není. Naopak capture videa ten efekt ještě o dost skryl, ve skutečnosti to bliká rychlejc/častějc.
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í
19.8.2009 18:30
.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)
21.8.2009 06:36
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
21.8.2009 09:41
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
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.
20.8.2009 08:31
Nicky726 | skóre: 56
| blog: Nicky726
20.8.2009 09:16
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 09:52
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 09:53
thingie | skóre: 8
20.8.2009 10:03
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
20.8.2009 10:06
thingie | skóre: 8
20.8.2009 09:57
Nicky726 | skóre: 56
| blog: Nicky726
20.8.2009 14:46
Nicky726 | skóre: 56
| blog: Nicky726
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.
Jasne. Zajimave by bylo mit softwarovou implementaci XRenderu pomoci podobneho efektivniho blitteru.
Myslel jsem to tak, ze se pak muze srovnavat HW implementace XRenderu se SW implementaci XRenderu, takze v obou bude zahrnuta stejna rezie.
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.
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).
> 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).
> 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.
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.
> 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.
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 :)
> Č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.
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.
20.8.2009 20:44
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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!
20.8.2009 20:45
thingie | skóre: 8
> 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.
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 ).
20.8.2009 20:28
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
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é.
20.8.2009 21:17
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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ý dojemNeplete si čirou náhodou NX s Xkama po síti(XDMCP a nebo ručně)?
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.
28.8.2009 10:39
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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
artefaktya 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.
28.8.2009 10:48
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Diskuse nad stavem Gtk, to raději založte nový článek, to už by jsme se dostali hodně jinamOmlouvá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?
28.8.2009 13:26
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
> 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?
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.
28.8.2009 13:21
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
20.8.2009 20:31
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Kromě podpory síťové vrstvy v X.Dle mého názoru, by naopak synchronizace síťovému provozu moc ulehčila.
20.8.2009 20:42
thingie | skóre: 8
20.8.2009 20:46
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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)
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?
20.8.2009 21:08
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
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.
20.8.2009 21:19
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
28.8.2009 12:55
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
"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?
20.8.2009 21:24
thingie | skóre: 8
20.8.2009 21:29
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
> 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.
28.8.2009 07:47
thingie | skóre: 8
> a tohle < 1% negativně ovlivňuje 99% uživatelů.
A to je naprosto nepodlozene tvrzeni. Viz mnou uvadeny priklad s OpenGL.
20.8.2009 20:49
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
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.
20.8.2009 21:04
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
> 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.
20.8.2009 22:07
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
20.8.2009 22:24
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
Co takhle ještě lepší, namapovat ten buffer přímo do kompozitního bufferu. Efektivně využít kompozitního manažera. Osobně jsem doufal, že už to takle funguje. Že nepotřebeujete žádné XShm (mimochodem, kontroloval jsem log a 100% je zapntý? Mandriva 2009.1) ale klienti kreslí přímo do bufferu kompozitního manažeru a pak se celý buffer jednorázově překlopí do videoram.
No neříkal jsem, že kompozit je super věc :)
28.8.2009 01:01
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
> 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.
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.
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.
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.
… 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.
Zajímavá shoda okolností. Nejspíš jde o jedno z bolestivých míst.
20.8.2009 12:50
Jardík | skóre: 40
| blog: jarda_bloguje
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.
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.
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.
27.8.2009 22:36
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
To asi zase není reakce na mě, co? Zkus GruntaCo 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.
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.
> 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.
28.8.2009 01:10
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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é?
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).
28.8.2009 12:43
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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?
20.8.2009 12:42
Jardík | skóre: 40
| blog: jarda_bloguje
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ý).
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.
20.8.2009 12:45
stativ | skóre: 54
| blog: SlaNé roury
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.
20.8.2009 18:58
stativ | skóre: 54
| blog: SlaNé roury
?? 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í.
21.8.2009 09:26
stativ | skóre: 54
| blog: SlaNé roury
20.8.2009 12:56
Jardík | skóre: 40
| blog: jarda_bloguje
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á.
20.8.2009 22:18
Jardík | skóre: 40
| blog: jarda_bloguje
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.
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.
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).
23.8.2009 00:42
Jardík | skóre: 40
| blog: jarda_bloguje
protoze prekreslovani okraje bude brzdeno tim prekreslovanim obsahuTo platí ve všech window managerech kromě kwinu, kde se čeká na kwin
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.
> 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.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.