Názory k článku
Xgl: Hračka nebo nástroj?

mne sa ako najlepsia funkcia XGLka zda byt to zoskupenie okien po stlaceni F12. Okna sa rozmiestnia vedla seba po celej obrazovke a po kliknuti na okno sa priblizi na vrch.

Suhlas! a tu kocku tiez by som nedaval ako efektnu hracku, pri praci z gimpom sa to hodi, ked potrebujem nazriet na iny obrazok alebo ine okno (napr. rychle porovnavanie) a v zapati sa vratit spat a pracovat dalej... proste nepripada mi to ako hracka.

Toto nie je argument.

V existujucich windowmanazeroch mas virtualne plochy, ktore sa prepinaju okamzite, a nie cez "uzasne" otacanie kocky, ktore aj tak len zdrzuje.

Užitečnost čehokoliv hrozně závisí na individuálních vlastnostech toho, kdo věc používá. Já například po něčem jako je "kostka" toužím už dlouho, přičemž plochy mi nepomáhají ale matou mě. Mívám totiž současně otevřeno hodně oken různých aplikací. Současně mám hodně špatnou mechanickou paměť - jaktěživo si nejsem schopen zapamatovat, co kde mám. Vždycký jistě "vím" že "tohle je na téhle ploše" a kliknu tam a ejhle, ono to tam není. Většinou se trefím tak na třetí čtvrtý pokus - přičemž se mi stává, že zapomenu i to, že na plochu X už jsem kliknul a zjistil že to není ona, takže klikám znova. Dost frustrující.

Zároveň mám ale hodně silnou prostorovou orientaci a "prostorovou paměť". Je to zvláštní, ale prostě vím, kde v prostoru tu hledanou aplikaci mám a na kterou stranou mám tu kostku natočit. Pořád si udržuju v hlavě, kde v prostoru vůči té kostce jsem. Mou orientaci v prostředí to zvyšuje brutálně.

Navíc bych chtěl zdůraznit, že Kororaa a podobne hrátky jsou jen pro ilustraci technických možností. Je teprve potřeba pro to vyvinout aplikace - ta možnost tu je, a možná se objeví zcela nové koncepty ovládání aplikací i aplikace jako takové atp.

Souhlas, posouzeni toho, co je vyznamna vlastnost a co prkonina na efekt, je hodne individualni a zavisi na zpusobu prace s pocitacem i na tom, k cemu kdo pocitac potrebuje.

Ja si taky pracovni plochy pamatuju prostorove (2D je taky prostor:), ale prekvapuje me, ze ma nekdo lepsi pamet na 3D nez na 2D, kdyz 2D je o dimenzi jednodussi :)

Hlavne proto, ze ani v 2D prostoru se nepohybuju primo, ale pomoci klikani do apletu. Kdysi jsem zkousel aktivni hranice pracovni plochy - proste jsem mel 2D prostor z mozaiky ploch a vedel jsem, ze k tehle aplikaci potrebuju proste mysi prejet vlevo nahoru za okraj soucasne plochy a k tomuhle oknu zas vpravo nahoru. Na orietnaci to bylo dobre, ale zase pouzivam panely, ktere mam skoro na kazde strane plochy, a ktere mam nastavene jako schovavaci, protoze mam notebook s pomerne malym displejem. Z nejakeho duvodu se mi proste nepodarilo nastavit, aby to rozumne fungovalo - furt jsem mel problemy s podivnym kmitanim tech panelu atp. Kdyby mi nekdo poradil jak v KDE rozumne nastavit neco jako "pri pridrzeni praveho mysitka s pohybem mysi pres okraj plochy nevystrc panel ale prejed do dalsi plochy", bylo by to supr a dost by mi to pomohlo.

Já nikdy nepřepínám klikáním na ikonky ploch, osvědčily se mi klávesové zkratky CtrlAlt + Sipka vpravo nebo vlevo.

Tak ja mam naprosto stejnou prostorovou orientaci... a zaroven presne stejny handycap jaky jsi popsal... ale neumim si zatim predstavit jak by mi to zminovane rotovani kostky pomohlo pro efektivitu prace. Ale vyzkousim Kororu-xgl mozna na neco prijdu :-))

Na preskupeni oken ale neni vubec potreba XGL, to uz umi VM davno.
Jen se ti presouvaji pevna okna, ne gumova....

Přesně tak. Všechno ostatní jsem ochoten oželet, ale po tom, co jsem měl možnost pracovat s Apple Mac OS X na iMacu, tak mi funkce Exposé kdekoli jinde strašlivě chybí. Už se nemůžu dočkat 25. 4. 2006, kdy vyjde openSUSE 10.1, které by už Xgl mělo umět. Tohle (a aktuální distribuční kernel, aby mi chodil DVB-T tuner) jsou dvě hlavní věci, proč chci upgradovat ze Suse 9.3.

a kompose neznate?

Znám a používám. Ale je to velmi chabá náhrada. (Navíc umocněná tím, že v GNOME, které používám, ne všechny funkce zcela správně fungují.)

> Dokážu si představit, že si pustím třeba televizi v rohu a nechám ji tam běžet,
> ale průhlednost mi bude spíš vadit

Vzdyt prave pruhledne okno TV v rohu je naprosto revolucni funkce - muzu v klidu brouzdat na internetu, soucasne sledovat v rohu bezici TV a pri tom porad prectu text v rohu browseru, protoze okno TV bude pruhledne!

To fakt nechapu, proc by mi mela pruhlednost TV spis vadit?

jj, suhlasim s tebou .. mne osobne sa prave ta featurinka velmi paci - robim si svoju pracu a dole v pravo mi bezi telka (klipy), ktore su priehladne ..

mna osobne tiez prekvapil ten vyrok ..

Vam funguje TV aplikace pod XGL? Jede to normalne, nebo se musi neco cekde donastavovat? Ja pouzivam TvTime, zvuk jede OK ale misto obrazu mam zelenou rozmazanou plochu.(tuner cx8800, gr- GF6600GT)

nainstaloval jsem si Xgl do Debianu podle nějakýho stupidního návodu přes alien a nejde mi tam ani mplayer, natožpak nějaká openGL aplikace - zelená rozmazaná plocha, kde se to nastavuje by mě taky zajímalo...

mne to slo uplne v pohode, ale zial mam slabu grafiku na akcelerovane video a tak som to uz odinstaloval.. no baliky mam stale tusim niekde odlozene, aj startup skripty

Pozivam ubuntu a s xgl bezi xawtv s parametrem xawtv xdtv -noxv
takze ji poustim takto a grabdisplay jinak greenscreen

ta realna pruhlednost mi taky pripada jako supr vec. cato delam v jednom okne neco, co zavisi na necem, co mam v jinem okne - a kdyz zapomenu presny stav, tak to zas musim preklikavat a hledat, ztracim nit...

casto taky delam neco podle navodu, ktery mam v browseru - pripada mi moc uzitecne mit moznost proste to "videt pod oknem", prepisovat radky kodu presne do editoru - s mou pameti se jinak musim prepinat po cca peti znacich, jinak tam mam milion chyb... a pak zas hledat kde jsem skoncil, hledat myslenky, znovu prepnout...

a to uz vubec nemluvim o tom, jak supr by mi pripadalo, kdyby bylo mozne delat v plose, koleckem mysi si ji zpruhlednit, ale nejen opticky ale i funkcne - aby bylo mozne mysi sahnout "pod hladinu", uchopit objekt, umistit ho na horni plose ("na hladine") presne tam kam potrebuju a zase znepruhlednit "hladinu" a pokracovat v praci. At. - nemam vymyslene nic konkretniho, ale dokazu si predstavit, ze se muze objevit spousta uplne novych zpusobu prace s daty.

To s tim sahanim pod hladinu uz je v proposals na nove pluginy do xgl.

Plocha rozdelena do hladin bude v Plasme a hodne me zajima jak to daji dohromady s Xgl...

Na Plasmu se osobne hodne tesim a jsem zvedavy. To jen tak na okraj - dost me zajima, jak vlastne funguje akcelerovany desktop, co vsechno bude mozne s tim delat - to jen tak motivacne, kdyby nahodou nekdo jako Karel o tom chtel napsat podrobnejsi clanek;-)

mozno sa to tu uz riesilo - ale zaujimalo by ma, aky dopad bude mat xgl (alebo to druhe riesenie od redhatakov) na spotrebu.. na desktopoch je to samozrejme jedno, ale ak notas vydrzi kvoli xgl o pol hodku menej, to by bolo celkom neprijemne...

V xgl vacsinu tych efektov zariaduje OpenGL/3D na grafickej karte. Karta asi nebude zrat viac alebo menej podla toho ci sa pouziva OpenGL akceleracia.

no urcity rozdiel tam urcite bude. Staci sa zamysliet nad tym, ze ta priehladnost znamena v skutocnosti celkom peknu zataz na fillrate. Tie texturovacie jednotky ktore sa pri tom vyuziju urcite spotrebuju viac, ako default bit blit operacie pri normalnych okienkach. Navyse, doteraz sa prekreslovali zvacsa iba casti plochy ktore sa nejak zmenili. V xgl sa to bude predpokladam chovat skor ako nejaka hra, kedy sa budu stale dookola renderovat vsetky okienka.

Na druhé straně by se mohla o něco snížit zátěž CPU, takže se to možná vyrovná, nebo spíš ten nárůst odběru elektřiny nebude tak markantní.

To, zda desktop umi nebo neumi 3D akceleraci, nema nic spolecneho s tim, jak videokarta funguje. Program napriklad nema moznost vyuzivat 3D rozhrani a funkce, ovsem videokarta presto ve 3D modu jede. V dnesni dobe se uz snad karty bez 3D nebo s oddelenym 2D a 3D nevyrabi, bylo by to zbytecne drahe a velke. Zobrazeni 2D textury (a okenko neni nic jineho) pak tedy neni nic jineho nez zobrazeni 3D textury v ortogonalnich souradnicich. Vymyslenosti jako odpojeni privodu proudu do nekterych casti obvodu se sice obcas objevi, ale pokud vim, efektivni vyuziti je nulove. To uz spis notebookum pomuze powerstrip a zasadni snizeni frekvence cele videokarty. Je to zvlastni, ale akcelerovany desktop je schopen rozumne fungovat i pri nizsich frekvencich, pri kterych uz klasicky desktop miva problemy. Zrejme to souvisi s prenosem dat mezi pameti pocitace a pameti videokarty.

Co se prekreslovani tyka, tam se situace trochu zlepsi. V klasickem i akcelerovanem desktopu si aplikace vzdy prekresluje to, co sama potrebuje. Tedy to, co se zmeni. V klasickem desktopu pak navic musi reagovat na zmeny vyzadane window managerem - tedy kdyz mam dve castecne prekryta okenka a to horni posunu, musi se nove odkryta cast prekreslit. Akcelerovany desktop to tak delat nemusi, protoze kazde okenko si defakto kresli do vlastni obrazovky a ty jsou pak skladany virtualne, nikoliv napevno. Posunuti okenka pak znamena pouze to, ze se prislusna textura vykresli na jine misto. Aplikace vubec zpravu o zmene vykreslovane plochy nemusi dostat. Ovsem pokud vim, tak stejne dostane - pro jistotu, aby se hure napsane aplikace nezacaly chovat "divne".

A 3D desktop samozrejme neni prekreslovan jako hra neustale - prekresli se sice cely, ale pouze pokud se nektera z textur zmeni. A to prekresleni je prave diky akceleraci rychle - pregeneruje se jen ta textura, ktera se zmenila, a jejich poskladani je uz bez vetsich problemu. Tedy pokud nemam onboard grafickou kartu se sdilenou pameti, coz byva jediny skutecny problem notebooku.

Přesně tak, v žádném případě obraz = jedna velká textura. To je blbost. Ze článku to vyplývá.

To se pekne pletete. Moderni karty pri praci v 3D zvysuji kmitocet jak sveho jadra tak i pameti a spotreba muze vzrust i radove! I kdyz nepocitam, ze xgl bude nejak masivne vyuzivat shadery :-)

Ja som zase cital nazor jedneho notebookara na itnews.sk a citujem:

"vydrz ti to zas tak velmi neznizi. pre ati x300 v battery mode mas spotrebu
idle 1.61 W a 100% zataz 2.74 W = nie je to az tak vela. netestoval som vydrz ale typujem znizenie max 10min" (koniec citatu)

Kedze spotreba CPU je radovo v desiatkach W (pokial viem, notebookove CPU potrebuju bezne aj 20-30W) tak prenesenie vacsej casti grafickych vypoctov na GPU by mohlo pokojne spotrebu aj znizit. GPU sa dnes vyrabaju efektivnejsie a lepsimi technologiami nez CPU. A navyse, na graficke operacie su (celkom prirodzene) omnoho efektivnejsie.

no tak ak ma notebook hw control neklame, ma moj notebook cely, ked ide na baterie (so sputenym powerplay atd...), spotrebu 13-15 W.. to je grafika, ram, display, disk... 2.5 W by mi teda z baterie uzralo celkom podstatnu cast :-)

uvidime - mozno to xgl este chlapici zoptimalizuju a bude to mat ludove naroky :-)

tie udaje o spotrebe su odtialto: http://www.thinkwiki.org/wiki/ATI_Mobility_Radeon_X300 . kororaa isla plynulo s cpu (800) aj gpu ( 120/105 ) na minime = na baterku minimalny vplyv

Spousta grafaren ma ve 2D podstatne nizsi spotrebu a prave pri prechodu do 3D rezimu se zvedaji frekvence a tim i spotreba.

To platilo tak pred 5 lety, kdy karty pro 2D a 3D mely ruzne obvody. Dnes se to jiz nevyplati a vse jede ve 3D. Karty pak umi podle zateze menit frekvenci, ale to je skutecna reakce na zatez, nikoliv na rezim zobrazeni 2D/3D.

Ostatne, i kdyz mate neakcelerovany desktop, muzete mit obvykle v okne spustenou akcelerovanou OpenGL aplikaci. To samo o sobe ukazuje na skutecnost, ze karta ani v zadnem 2D modu nejede. Doby, kdy hry bezely akcelerovane jen ve fullscreenu, jsou jiz minulosti.

Já mám grafiku s GeForce 7800 GS od Leadteku, tedy novinku, nic stareho. Dokud jedu v 2D, tak vetrak neni slyset, staci ale abych spustil glx gears a vetrak se okamzite rozhuci jako blazen. Takze mit 3D akcelerovany desktop by pro me znamenalo, ze mi porad bude hlucet vetrak, coz teda nechci. Nastesti ani jeden z uvedenych efektu se mi nelibi, pruhlednost povazuji za hloupost, gumova okna a kostku taky, tak si ergonomicke ovladani nepredstavuji.

glxgears je napsan tak aby vyuzil veskery vykon v opengl naplno. V xgl pri bezne praci tj. pouziti pruhlednosti atd. byste tu kartu rozhodne nezatizil jako pri glxgears.

nVidia vetrak zrychli automaticky po spusteni cehokoliv 3D. nastesti se da zese zpomalit pomoci nvclocku.

Co ti brani v tom stiahnut si live distribuciu Kororaa a vyskusat ci ti ten vetrak bude stale bezat?

Podla mna sa prekresluje len ked sa nieco zmeni. GLXGears prekresluju obrazovku co najviac to ide, teda karta maka jak diva. Ja som to skusal na svojom kompe a je to v pohode.

Moderni desktopove procesory maji velmi dobre rizeni spotreby. Intel ma SpeedStep a AMD C&Q. Pristi procesory od Intelu na tom budou jeste lepe.

Funguje to C&Q pod linuxem ? Samo, nebo se musi zapnout ?

cituji z wikipedie:
"Cool'n'Quiet can be activated in Microsoft Windows by going to the Power Options control panel and setting the "Power scheme" to "Minimal Power Management". Setting it to "Portable/Laptop" will also work. In Linux, Cool'n'Quiet is supported by the powernow-k8 kernel module. In FreeBSD, it is supported by the cpufreq(4) kernel module."

Jo, ten mam zakompilovany do jadra. Jestli to staci, bezva. Mel jsem obavu jestli nepotrebuju neco navic, jako treba nainstalovat powernowd, zkonfigurovat a spustit ...

no pokial viem tak nejaky daemon tam spusteny musi byt... Nastavis si profily a ten daemon ti bude podla potreby medzi nimi prepinat...

Ak sa nemýlim, tak v Ubuntu je to out-of-box. Osobne AMD nemám, tak musíš vyskúšať sám.

Nevim jestli se to netyka jenom speedstepu, ale demon neni potreba, je na to primo podpora v jadre, viz governor conservative a ondemand.

No, ja som toho nazoru, ze ked je CPU na max frekvencii a nic nerobi, tak ma spotrebu skoro taku istu ako na min. frekvencii. Mohol by to niekto odmerat (teda samozrejme ten, kto ma athlona64 a prislusny merak)?
Rozdiel je skor ked pustim nejaku hru, co ma jeden loop a pritom nepotrebuje taky vykon, tak vtedy je C&Q doost dobra vec (umelo znizim frekvenciu na najnizsiu a CPU ostane skoro studeny, hra bezi v pohode).

som to tak nemyslel ;-) tiez neviem, aky ma prinos pouzivanie pocitaca s 500W zdrojom (a to nepocitam, ak si nahodou k tomu nejaky blazon dokupi 21'' monitor :o))) na pisanie vo worde...
vsetci si povinne zacnu kupovat notebooky a hotovo - tie maju vacsinou spotrebu tak do 60-80 W :-)

ved hej no... nastastie :)

Ale z výkonu toho zdroje je patrné, že asi půjde o hodně žravý počítač.

Ja mam doma k PC pripojeny wattmetr, takze spotrebu hned vidim. Je to AMD Sempron 2100+, Maxtor 7200 ot. 80 GB ATA, Seagate 7200 ot 200 GB SATA, grafika nVidia 5200, pamet 1x 512 MB DDR, CDRW mechanika, Soundblaster 1024, firewire Kouwell karta, 2x sitovka s chipem Realtek 8139, zdroj nejaky obycejny 300 W.

Na tom je nainstalovany Debian SID (unstable) s Xorg. Mam defaultne zapnuto athcool. Kdyz nic nedelam, tak se spotreba pohybuje kolem 80 W. Kdyz zacnu prehravat video, tak spotreba vyskoci na 120 W.

ast

ono to na desktopech jedno nebude..
treba Nvidia 6600GT (a urcite i nektere dalsi karty) ma dva rezimy (kupodivu 2D a 3D), ve kterych funguje na jinem napeti a frekvenci jadra. u plno karet to muze zpusobovat vetsi hlucnost vetraku, v nejhorsim pripade i to, ze nekdo jel v 2D pasivne a ted bude mit hlucny pocitac nejenom v tuxracerovi:) coz by byl alespon pro me daleko vetsi problem nez nejakych par W navic.

Užitečnější by myslím bylo, kdyby spíše implementovali widgety na straně serveru a jejich volitelné bufferování. V současné době se snad překresluje celé okno aplikace, když se v něm něco změní a zbytečně se tahá po síti informace informace "jak vykreslit nový stav", místo "co se změnilo". Poslední problém je sice plnou akcelerací odstraňen přímým přístupem k hardware, ale i tak by myslím smysluplnější zabývat se tímto.
Možná se ale pletu - prý lze definovat nějaká podokna. Mohlo by to snad jít tak, že novým X serverům by noví klienti (gdk a QT) posílali pouze změny stavu widgetů, zatímco starým by posílali současné příliš nízkoúrovňové operace. Množina podporovaných widgetů by se mohla i časem rozšiřovat.

http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Distinguished03/MarkThomas.pdf
http://www.y-windows.org/


Stál by za úvahu i vektorový popis scény, přičemž by se před vykreslením vyrastroval, a takto uložil do bufferů, nebo chcete-li, zobrazoval přes OpenGL plně akcelerovaným X serverem. Na obrazovce s 640x480 by obraz vypadal stejně jako na obrazovce 5000x5000, pouze by se lišila jemnost grafiky. Odpadl by problém, při kterém si skoro každý dobrovolně snižuje rozlišení, protože na maximálním rozlišení podporovaném monitorem nejsou ikony a tlačítka vidět.
Toto by ale už nejspíš nešlo implentovat jako rozšíření X protokolu a vyžadovalo by to určitě hodně velký zásah do klientských knihoven.
http://www.fresco.org/

Uzivatele nezajma jak to funguje vevnitr, ale jak to vypada. Taky vetsina lidi pouziva X lokalne, ne pres sit. Takze ulety typu y-windows nemaj velkou sanci na uspech. Na sitovy GUI uz tu mame VNC, RDP a NX.
Vektorovy popis sceny je uz nakou chvili soucasti GTK vyuzivajici k tomu cairo.

> Na sitovy GUI uz tu mame VNC, RDP a NX.

S tim nesouhlasim, pouzitelnost VNC ve srovnani s X protokolem je dost mizerna (i na lokalni 100Mbit siti). Prece jenom X protokol resi prekreslovani mnohem chytreji a prace se vzdalenym systemem je mnohem zivejsi.

No a NX je ještě lepší, že jo. ;-)

Cele okno aplikace se prekresluje jen nekdy — konkretne kdyz pouzivate Javu/Swing nebo Gtk. Ty pouzivaji podokna jen nekde (resp. nikde) (a nekdy to dost vadi, zvlast Java/Swing s MDI pres JInternalFrame po siti je pekny maso). Qt pouzije okno na vse.

Zkuste si pustit xwininfo -tree -root

Inkrementalni zmeny samozrejme jdou i ted. Treba kdyz se zmackne tlacitko (ktere muze obsahovat nejakou dost slozitou vec uvnitr), neni teoreticky nutne prekreslovat ten vnitrek, staci posunout. Ale naprogramovat je to peknej humus, zvlast kdyz to tlacitko je castecne zakryte.

Ad vektorovy popis: Myslite neco jako DPS?

Díky.
Těch podoken v GTK+ aplikacích mi připadá celkem dost.

Tím vektorovým popisem jsem myslel cokoliv, co by jednoduše řešilo popsaný problémy. Sice existují SVG ikony, které lze zvětšovat, ale například s tlačítky a ikonami v aplikaci to už nejde.
Nevidím důvod, proč by mělo jít na monitoru bez problémů rozlišit jednotlivé pixely, místo toho by se mohla zjemnit grafika zvýšením rozlišení a vše na obrazovce zvětšit, aby se na to dalo dívat.
Jestli to lze udělat s Cairo nebo DPS, netuším.

No, ja si myslim, ze najlepsie by boli nejake parametrizovatelne display listy (ako su pri opengl, len trochu prisposobene). Teda by sa zavolalo napr. calllist(idtlacitko_up,10,20,30,40,"OK") a server by to cele vykreslil. Prinasa to sice niektore dalsie problemy (ako napr. ina farebna schema pre jednu aplikaciu by potrebovala asi mat vsetky listy vlastne a pod.), ale za pokus by to stalo, uz len preto, ze v pripade OpenGL to funguje skvelo.
Dalsia vec co ma napadla - hlavne pre pomalsie kompy - by sa mohlo oznacit zaciatok a koniec vykreslovania a server by to cele nabufferoval a potom vykreslil. Toto by spolupracovalo navzajom s window managerom. Odstranily by sa niektore neprijemne efekty ktorymi Xka trpia a zrychlilo by sa vykreslovanie, lebo najviac spomaluje latencia zbernice (prip. siete). A kedze toto nebudem mat nikdy cas skusit implementovat, mozem o tom len snivat.. :-(

bufferovanie apod. velmi uspesne riesi NX. odporucam vyskusat.

problemy s roznym rozlisenim by mal podla mojich info mat vyriesene mac os x, ktory vsetke generuje do pdf a nasledne zobrazuje cele gui cez opengl.

Zkousel jsem to na mem notebooku s integrovanym Intelem 915 (GMA900) a i kdyz samotny desktop byl s trochou nadsazky pouzitelny, jakakoliv dalsi akcelerovana aplikace uz nemela sanci. glxgears mi se spustenym Xgl davaly jen nekolik malo desitek FPS, bez akcelerovaneho desktopu pres 1100. To je 3D akcelerace stejne nepouzitelna i na silnejsich kartach, nebo je to jen vlastnost tech slabsich?

ja som to skusal na ati 9800pro a slo to tam slusne ,glxgears okolo 6000 fps ,ono 915 je tak na desktop ,na 3d treba cosi silnejsie .. :)

Clanek se mi nelibi pro svoji zaujatost. Autor proste nemam rad akcelerovanou grafiku a dava to najevo. Uplne stejnym zpusobem by mohl konzolista odsoudit X server (a deje se to).

Spravna otazka neni "proc jo?", ale Proc ne?

BTW: ja mam X server pod VESA rezimem a staci mi to...

Nejsem nijak zaujatý proti akcelerované grafice. Naopak několikrát jsem v článku napsal, že je to dobrá věc, která má budoucnost. Článek jen porovnává funkce aktuální podoby Xgl z pohledu uživatele. Samozřejmě máte pravdu v otázce „Proč ne?”. Akcelerovanou grafiku má dnes skoro každý. Ovšem chce to ještě nějaký ten vývoj.

Proc ne: Zveda se spotreba, hlucnost, neprinasi to (zatim) nic prevratneho .... staci ?

No nestačí :-) Možná tak Vám se něco zvedá :-PPP Můj notebook s integrovanou grafikou má stále normální provozní teplotu a nezaznamenávám v OpenGL aplikacích žádné nadměrné hluky...

Tzn neglobalizujte Váš problém, prosím.

presne jako ti uz nekdo odpovedel, na ntb mi to taky vubec nic nedela grafika mlci

Mohlo by to způsobit i toto

"To je perfektní jak se to sqele hýbe, ty voe průhledná okna, jde to i ve vindous? Ne? Já chci taky ten linuks!"

BFU mají rádi takové hračičky.

Tak to máš co dělat... Protože Vistu beta má už na svém stroji každej windowsí hračička v betě a ostrá je tu co nevidět.

To jste řekl dobře. Co nevidět :-)

Nemusim ani cekat na Vistu. Tohle Win umi už od verze 2000.

Nic proti linuxu ale funkce, ktere autor v clanku oznacil jako efektivni jsou ve win už poměrně dlouho - některe od 2000, jine od XP - s vyjimkou Akcelerovaného OpenGL. Tudy asi uživatele nepřetáhnete. Taková cesta bude možná až po bezproblémové komunikaci všech programů (například ve výše zmiňovaném clipboardu).

Jurodivy

WTF? Cetl jste vubec ten clanek?

Ale jiste, ze cetl. Vzdycky jsem prekvapeny jak malo toho mistni "diskutéři" vědí o svém nepříteli :-). 1. Průhlednost oken od verze 2000 win podporuji pruhlednost v API. Program ji může/nemusí použít. existují utility, které tuto vlastnost vnutí libovolnému oknu. 2. Zoom Existuje hned několik utilit poskytující tuto poměrně triviální funkcionalitu na windows systémech. 3. Přeskupení a přepínání oken přepínání oken se zobrazením náhledu okna poskytuje volne stazitelná utilita od MS pro Win XP. Organizaci oken win poskytovali vždy, neumí se ale vrátit do původního stavu. Tohle je tedy rozhodně výhoda MacOS a popisovaného řešení. Otázka je, kolik procent uživatelů tuto funkci potřebuje - osobně potřebuji okno skoro vždy maximalizované. Pracovní nástroje které používám spotřebují veškeré místo. 4. Akcelerované OpenGL Myslím, že tohle win neumí, ale nedokážu to posoudit. Nepotřebuji takovou funkci. Všechny tyto funkce lze zprovoznit na každém dostatečně výkoném hardwaru (dnes je to i nejlevnější nový počítač). Pokud vím XGL funguje jen na výběrových grafických kartách. Řešení může být sebevíc elegantní, ale pokud není použitelné, je v daném okamžiku na nic. To se samozřejmě může změnit. Upozorňuji, že moje původní reakce se týkala výhradně příspěvku Murděje Ukrutného: Mohlo by to způsobit i toto "To je perfektní jak se to sqele hýbe, ty voe průhledná okna, jde to i ve vindous? Ne? Já chci taky ten linuks!" BFU mají rádi takové hračičky. Osobně si myslím, že všechny zmíněné funkce jsou neefektivní. Jedinou efektivní vlastnost v článku zmíněnou (v epizodní roli - není předmětem článku) je přepínání oken. To ovšem hned několik utilit poskytuje i pro Win. Osobně mi přijde kontraproduktivní argumentovat pro linux znalostmi pocházejícími ze znalostí Windows 95. Je to směšné a lidi to spíše odrazuje ... Jakub Pehal (za svým názorem si stojím)

Ale jiste, ze cetl. Vzdycky jsem prekvapeny jak malo toho mistni "diskutéři" vědí o svém nepříteli :-).

1. Průhlednost oken
od verze 2000 win podporuji pruhlednost v API. Program ji může/nemusí použít. existují utility, které tuto vlastnost vnutí libovolnému oknu.
2. Zoom
Existuje hned několik utilit poskytující tuto poměrně triviální funkcionalitu na windows systémech.
3. Přeskupení a přepínání oken
přepínání oken se zobrazením náhledu okna poskytuje volne stazitelná utilita od MS pro Win XP. Organizaci oken win poskytovali vždy, neumí se ale vrátit do původního stavu. Tohle je tedy rozhodně výhoda MacOS a popisovaného řešení. Otázka je, kolik procent uživatelů tuto funkci potřebuje - osobně potřebuji okno skoro vždy maximalizované. Pracovní nástroje které používám spotřebují veškeré místo.
4. Akcelerované OpenGL
Myslím, že tohle win neumí, ale nedokážu to posoudit. Nepotřebuji takovou funkci.

Všechny tyto funkce lze zprovoznit na každém dostatečně výkoném hardwaru (dnes je to i nejlevnější nový počítač). Pokud vím XGL funguje jen na výběrových grafických kartách. Řešení může být sebevíc elegantní, ale pokud není použitelné, je v daném okamžiku na nic. To se samozřejmě může změnit.

Upozorňuji, že moje původní reakce se týkala výhradně příspěvku Murděje Ukrutného.

citace:

Mohlo by to způsobit i toto

"To je perfektní jak se to sqele hýbe, ty voe průhledná okna, jde to i ve vindous? Ne? Já chci taky ten linuks!"

BFU mají rádi takové hračičky.

Osobně si myslím, že všechny zmíněné funkce jsou neefektivní. Jedinou efektivní vlastnost v článku zmíněnou (v epizodní roli - není předmětem článku) je přepínání oken. To ovšem hned několik utilit poskytuje i pro Win. Osobně mi přijde kontraproduktivní argumentovat pro linux znalostmi pocházejícími ze znalostí Windows 95. Je to směšné a lidi to spíše odrazuje ...

Jakub Pehal (za svým názorem si stojím)

P.S.: Takhle to bude jistě lépe čitelné :-)

Ovšem pokud vím, žádná zavedená distribuce linuxu ve stabilní verzi nenabízí tuto funkcionalitu jako default. Vzhledem k množství podporovaného hardwaru by to byla sebevražda ... Když jsem si četl návod jak zprovoznit, zapnout a při neúspěchu vypnout xgl, nevypadalo to jako operace pro BFU. Obávam se, že by to pro něj byla konečná. Nerad bych ale, aby se diskuze zvrhla na flame o win. Šlo mi vysloveně o to, že tento nástroj těžko přitáhne běžného uživatele.

P.S.: Je mi buřt, že Vám je to buřt. Takže Vám to rozhodně nezazlívám :-)

Jenze cely tento clanek je o akcelerovanem(!) desktopu - coz Windows pokud vim proste nema. A ze to obchazi a poskytuje ruzne nahrazky, ktere se daji do systemu zakomponovat - kdyz dva delaji totez, neni to totez. Treba ta vami zminovana pruhlednost oken ve Windows - ve Windows je realna(!) pruhlednost? Mluvim o tom, ze textury aplikace vespod se prekresluji, ne o nejake "pseudopruhlednosti", ktera je v Linuxu samozrejme uz davno taky... mozna mi neco unika, ale podle me nic takoveho proste ve Windows neni.

To same dalsi vase namitky - nevim o nicem, co by ve Windows zoomovalo realne, nevim o nicem, co by preskupovalo a prepinalo realne plochy, ne staticke screenshoty ploch.

Uz vase poznamka c. 4 vzhledem k faktu, ze cely clanek je o akcelerovanem desktopu, svedci o tom, ze veskere vase namitky cili ponekud mimo. Coz nabyva na dulezitosti zejmena prihlednutim k faktu, ze jak bylo v clanku uvedeno, mnohe z tech hracicek slouzi hlavne k ilustraci technickych moznosti hardwarove akcelerace desktopu, jejichz podstatne vyuziti teprve prijde. Coz rozhodne na soucasnych Windows neni mozne, protoze pokud vim akcelerovany desktop proste neumi. A ze je mozne pomoci ruznych fint a za zvysenych naroku na hardware nektere ty veci emulovat - uz jsem psal... kdyz dva delaji totez, neni to vzdy totez.

windows pouziva na priehladnost alfa kanal, cize predpokladam ze je vyuzita 2d akceleracia na alpha blit. pokial ide o prekreslovanie aplikacii "vespod", tak ich update moze byt ovplyvneny odobranym focusom. ale neviem, nikdy som to nepouzil.

1. Moje reakce se týkala diskuzního příspěvku. Ne článku. Přečtěte si pozorně na co jsem reagoval.
2. Co se týče funkcí: pro uživatele není důležité jak, ale co dělají.
3. ano, ve windows je implementovaná skutečná průhlednost. Ne zobrazování plochy v pozadí aplikace.

1. diskusni prispevek se tykal clanku, IMO by se jej mela tykat i reakce.
2. pisete to, jako by to nesouviselo; navic nechapu, na co timhle reagujete
3. uprimne receno, neverim. jak ve Windows (vami zminovanych 2000 nebo XP) desktopu nastavite, abych mel pruhledna okna a pod nimi se mi prekreslovaly aplikace vespod?

Ta priehladnost funguje vo windows tak ako ma, dokonca je akcelerovana (napr. skuste chytit a tahat obrazok v opere, moze byt kludne aj na celu obrazovku). Windows maju vsetky funkcie na kreslenie implementovane softwarovo v GDI a vyrobcovia ich mozu ovladacmi nahradit, co aj robia. GUI windows je celkovo rychlejsie, ale aj v safe rezime, ked nie je akcelerovane - asi je to maximalne mozne zoptimalizovane. BitBlt sa robi cez DMA uz od doby windows95 a je to poznat, X server to podporuje mozno tak s prislusnym modulom v jadre, ale drviva vacsina ovladacov grafik na toto prislusnu cast v jadre nema. X server je vobec az moc rychly na to, ze nema akcelerovane ovladace tak ako windows. GLX to zlepsi tym, ze hw akcelerovane OpenGL by bez toho ovladaca v jadre fungovalo len tazko, takze to vlastne zastancom X servera - ako samostatnej aplikacie - niekto celkom sikovne vnutil.

Tak jsem zkusil ve Windows tahat obrazkem v Opere - a nic zajimaveho jsem nevidel, nic co by zavanelo realne prekreslovanou pruhlednosti. Co jste tim jako myslel? Proc ma porad pocit, ze cele tohle vlakno probiha stylem "ja o voze ty o koze"? Opakuji otazku (byt jsem ji, pravda, puvodne nemyslel na vas) - jak ve Windows XP nebo 2000 zapnout realnou pruhlednost ploch aplikaci?

Celkovou vetsi rychlost neakcelerovaneho GUI ve WIndows oproti Linuxu bych nezpochybnoval, vzhledem k vetsi provazanosti s jadrem.

aplikace to musi podporovat. napriklad icq klient miranda. pak jsou utility, ktere to zapnou na libovolne okno, ale ja to nepouzivam, takze bych je musel vygooglit.

je pravda ze v mirande to fakt vali bez problemu na mym pracovnim notesu s XPP na integrovane grafarne ...

No neviem, mne to fungovalo v tej opere vsade, obrazok sa pri jeho potiahnuti proste spriesvitni. (dufam, ze ste netahal nejake flashe..) A mirandu mam tiez normalne polopriesvitnu, pod nou je vsetko ako ma byt a podla rychlosti prekreslovania pri pohybe oknom to musi byt hw akcelerovane.

pri kartach od ATI sa to da zapnut v nastaveniach karty (myslim ze right click na plochu>properties atd. ale presne si to uz nepamatam)

Omlouvám se za překlep. Ostatní výše.

Dobrý den,
podle mě bude největší přínos XGL v tom, že ulehčí práci CPU a výpočetně náročné operace jako překreslování obsahu oken při jejich přesunu a podobných akcích, které GPU dokáže počítat mnohem rychleji a efektivněji a tudíž i s nižší spotřebou el. energie.

Já osobně doufám, že tzv. gumová okna půjdou vypnout, protože efekt gumy pravděpodobně vypočítává stále CPU (teoreticky by to šlo naprogramovat pomocí OpenGL shaderů). Namapování textury na deformované okno už sice provádí GPU, ale když jsem tuto vlastnost měl možnost testovat na LinuxExpu, tak si to vzalo tak 30% výkonu procesoru ... děkuji nechci a bude to první věc, kterou vypnu.

Dlaší věc, kterou jsem se zatím nikde nedozvěděl, je jestli XGL bude schopno akcelerovat vykreslování jednotlivých elementů GUI, jako jsou posuvníky, vyrenderované okno prohlížeče, atd. Zajímalo by mě jak v tomto případě spolu souvisí a spolupracuje GTK, Cairo, Glitz, XGL a OpenGL?

XGL a akcelerace OpenGL jsou podle mě v článku dány do trochu zvláštní souvislosti, protože XGL je akcelerované právě pomocí OpenGL. Pokud má někdo nainstalované ovladače od firmy nVidia , ATI nebo 3DLabs tak může využívat hardwarové akcelerace OpenGL už dnes a nějaké XGL ho vůbec nemusí trápit

V uzavřených ovladačích od firem ATI a nVidia vidím největší problém XGL a jiných akcelerovaných desktopů, protože jejich kvalita a stabilita nenní nejlepší. Pokud vám kvůli mizernému ovladači správně nefunguje hra nebo váš oblíbený 3D modelář, tak se zas tak moc neděje, ale když kvůli tomu nefunguje nebo padá celý desktop, tak to je docela zlý a špatně řešitelný.

Nicméně si myslím, že XGL je velký přínos a těším se na něj.

Jirka

Myslim ze gumovy efekt (wobbly plugin) nepocita cpu (alespon u me nevidim zadny narust) a rozhodne jde zapnout/vypnout + podrobneji nastavit, stejne jako vsechny ostatni pluginy.

Ta gumárna hlavně nezatíží nijak extrémně systém, je to jen o jednu transformaci víc, to si každá slušná grafická karta jen pochrochtá.

tak mi prosim vysvetlite, preco dosahuju tie iste karty nizsi vykon s rovnako dobrymi ovladacmi? (napr. doom3)

unreal tournament 2004 -> az 150fps rozdiel!!!

http://www.anandtech.com/linux/showdoc.aspx?i=2241&p=4

tu je vidiet, ze na karte 5700 ultra ma hra v linuxe "nehratelny" framerate

ukazuje to pomer kvality ovladacov. ten sa podla mojho nazoru nezmenil.
a treba brat do uvahy vtedajsie karty, pretoze aj na tych by to malo bezat (a nie sa plazit)

a ako oznacite moju GeForce2 MX?
ta zvlada HalfLife2 hratelne. spusti doom3 s obcasnym sekanim. pod Linuxom je sekanie vacsie (tych par fps urobi svoje).
ale teraz neriesim, ze graficke karty to dnes zvladnu a tych par fps si nikto nevsimne - ale znatelny rozdiel medzi vykonom ovladacov je

Muhehe, HL2 na GF2MX. Jsi trapak. Asi by ti vypadli oci kdybys to videl na rychle karte s DX9. Muhehe. Hratelny :-))) Tak dobre jsem se nad lidskou blbosti dlouho nepobavil.

a ty si drzka. nepozeram na vzhlad, ale na hratelnost. o nic som neprisiel, ta hra mi nedala menej nez tebe.

Jasne. Trabant taky jezdi stejne jako BMW, ze trubko? Uznavam, ale ze ujet 1000 km trabantem nez tim BMW musi byt taky zazitek ;-))) Ale si trosku jinej, ze? :-)))

som. prekaza ti to?
a ten zazitok nebol ani trosku iny. si mimo.

jj, kdyz me opustila moje grafika, tak po dobu reklamacniho rizeni jsem oprasil starou GF2MX a zasnul jsem, co za nove hry jsem si mohl zahrat. jasne ze misto vlnek v mori jsem mel jen modrou vodu, ale slo mi o hratelnost....

!!! Nesmej se ty posmevacku :) !!!

tak si to skus:
1,2Ghz Thunderbird
256MB RAM (SDRAM)
GeForece2 MX200 32MB

half-life2 hratelne, doom3 nehratelne.
(hl2 mi islo spustit aj s TNT2 32MB, ale v urcitej casti hry spadla - to sa dalo cakat, pretoze hardwarovo nepodporuje verziu DirectX, ktora je uvadzana v README)
quake4 nespusti, pretoze procesor nema SSE instrukcie.

Kdybych si právě koupil novou grafigkou kartu, tak by první, co bych udělal, určitě nebylo to, že bych hledal na internetu diskuse a posmíval se všem, kteří mají něco slabšího. :-\

Ze maju milion <>ovin este neznamena, ze su dobre. Pokym nebudu open source, tak nikdy poriadne nebudu.

Nikoliv, pouze napsal to co většina tuší.

Jeste bych doplnil, ze existuje firma Matrox, ktera ma sice krasne barvy, ale nejhorsi ovladace vubec. Nastesti pro majitele existuje rakusan kterej originalni drivery z 13Dec05 upravil tak, ze je mozne je pouzivat i s 2.6.16 i X.org 7, akorat porad ten driver neumi to co se slibuje na obalce three heads independent a linux compatible out of a box.
nVidia ma sice obecne nejhnusnejsi barvy, ale drive pro linux jsou obecne velmi v pohode uz nejaky rok mozna dele. Ati ma s drivery obcasne problemy a kvalitou barev je IMHO nekde uprostred.

Zdravím všechny

Jen krátkou úvahu na téma XGL. Nejsem nijak zběhlý v systému Linux ani Windows a na problém se dívám jako obyčejný uživatel ještě k tomu odchovaný prací na počítači Amiga.
Když vývojáři navrhovali koncept Amigy někdy v polovině 80 tých let, tak si dobře spočítali, že výkon procesoru Motorola 68000 na 8 MHz nestačí k tomu, co od systému požadovali. A proto tam zabudovali sadu pomocných koprocesorů pro grafiku, zvuk, obsluhu FDD a podobně. Mě jako uživatele z toho zajímá fakt, že pohyb kurzoru myši je ošetřen pomocí tzv. sprite ( ani nevím co to je, ale laicky si to představuju jako vyhrazený blok dat v grafické paměti) který grafický koprocesor přesouvá v grafické paměti sem a tam. Kurzor myši sedí na obrazovce jako přibitý, při pohybu necuká, nepobliokává atd. Hlavní procesor se o jeho pohyb nestará. To samé se týká třeba tvorby filmových titulků a jejich pohybu po obrazovce odspoda nahoru - opět to řeší grafický koprocesor, navíc s tím hýbe v synchronizaci s řádkovým rozkladem TV obrazu, takže titulky na obrazovce jakoby sedí, pohyb je plynulý a nic se nerozsypává.
Pokračovat můžu navržením desktopu, kdy vývojáři celkem správně usoudili, že na desktop jako takový stačí relativně málo barev a malé rozlišení (WB 3.0 má defaultně 640x256 a 4 barvy) I s tímto málem jdou navrhnout okna, která vypadají skoro tak jako na win 95 ve smyslu posuvníků, gadgetů atd, Stejně jako podklad pro ikony, který je "promačkávací" takže uživatel po promáčknutí ikony ví, že ji nakliknul, ne jako ve win kde ikona tak nějak zmodrá. Při tak malém rozlišení si můžu pracovat s ikonami na ploše, ale co práce s grafikou atd? To vyřešili úplně geniálně, systémem tzv. virtuálních obrazovek. Tuto funkci bych přirovnal k oněm více plochám na Linuxu, které si přepínáte buď myší, nebo kombinací kláves, tady na Amize jsou ty plochy naskládané za sebou, vy máte v předu plochu systému 640x256 4 barvy, za tím je plocha malováku DeLuxe Paint 640x512 256 barev, za tím je plocha programu Page Stream (DTP) 1280x512 8 barev atd... To kouzlo je v tom, že děláte v systému, pak najedete myší na horní Menu lištu, chytnete ji a stáhnete ji kousek dolů, a pod tím vidíte tu obrazovku v jiném rozlišení a počtu barev. Samozřejmě to jde přepínat kombinací kláves, nebo myší. Zase se o to stará grafický procesor.
Toto využití grafických karet ve prospěch uživatele mi v PC světě docela chybí. Teď se zdá, že by se vývoj mohl pohnout tím správným směrem, otázkou je, aby se ta technická možnost akcelerace nezvrhla zase jen v dokrášlení desktopu bez pomoci uživateli. Na závěr ještě upozorním za naše tělesně handicapované uživatele, že na takový 3D desktop bude mnohem obtížnější napsat například slepecké prostředí - velmi dobře znám svého kamaráda, který pracuje s PC díky takovému prostředí a je rád, že většina aplikací má textově programovaná menu a tlačítka, které je to schopno přečíst.
S pozdravem Michael Kročil Třebíč

ovladace od ati nie su uzavrete, pokial viem :-)

Nemohla by byt podpora OpenGL aj priamo v GIMPe?
Aby sa zrychlili niektore ulohy. Ako je Zoom a posuvanie.

Ale pri panoramach (20.000 x 5.000) mi asi nic nepomoze, ze? ;-(

To by sakra melo pomoct. Kdyz bude cele panorama v graficke pameti a bude se jim jenom posouvat a zoomovat melo by to byt radove rychlejsi.

Otázka stability X11R7.0 je hloupost, protože X11R7.0 je to samé, co X11R6.9, ale pro kompilaci je použit autotool místo imake a modulární strukturu (není duplikován X server kvůli jiným graf. kartám, tj. něco jako moduly v jádře). Jinak je X11R7.0 i X11R6.9 naprosto totožné, viz http://x.org. Takhle plkat může jen ten, kdo nepřenese přes srdce, že jeho (TM) distribuce je (stále) 100 let za opicemi.

Distributoři se Xgl nebrání, jen ji nemohli zatím zařadit, protože to bylo vyvinuto in-house v SUSE (tj. zveřejněn byl až výsledek). Fedora Core 5 obsahuje obdobnou implementaci, ale vyvíjenou otevřeným způsobem, viz http://fedoraproject.org/wiki/RenderingProject. Oba projekty navíc mají být sloučeny, resp. Xgl bude adoptovat věci z AIGLX, viz http://www.redhat.com/magazine/017mar06/departments/fedora_status/#XGL_To_Adopt_AIGLX_Changes

Ty "efekty", nad kterými autor ohrnuje nos, jsou hlavně o prezentaci možností této technologie a ne o jejich cílech. Tj. nikdo se nepsal s Xgl nebo AIGLX proto, aby šlo šaškovat po ploše s gumovými okny. Důvod, proč to vzniklo (a co autorovi "jaksi" uteklo), je přinést 3D akceleraci do grafického prostředí na systémové úrovni a ne prostřednicvím speciálních ovladačů (aby se příslušný kód pro 3D neduplikoval). X Window System je historicky v podstatě bez akcelerace, v současnoti maximálně pouze s 2D akcelerací a to ještě s výjimkami a nestabilitou.

Skutečnost, že si autor nedokáže představit použití 3D akcelerace v normálních aplikacích neznamená, že to je k ničemu (viz např. distribuce renderování Quake na 24 monitorech - http://cdr.cz/a/17039). Využít se to dá např. při velkoplošných projekcích (prezentace) nebo při zobrazování při modelování a renderování (při vysokém rozlišení).

To že video jede "přes roh" znamená spíše to, že je celý systém dobře navrhnut a nemá zbytečná omezení. Mám pokračovat?

Vyborne, diky za odkazy.
Jako uzivatel Gentoo jsem se o AIXGL dozvedel az z Changelogu X. Kdyz jsem pak zbezne patral co to vlastne je, prislo mi ze se jedna o akci typu "hura, my to mame taky". Sice to umi zhruba polovinu toho co XGL, ale co uz.
Spis nez popis XGL (ktere si koneckoncu diky projektu Kororoa muze vyzkouset kazdy) bych tedy uvital srovnani XGL a AIXGL a kterym smerem se vyvoj bude pohybovat.
Kazdopadne mi osobne neprijde nutne mit dva projekty, ktere delaji zhruba totez.

Jo jo, pripominka hezka a je videt ze autor je mimo. Ale pak me napadla otazka, proc clanek nenapises Ty, ktery tomu tak rozumi a musi se cist pak nejake plky... ?

OT: *flame* Buy Apple use Mac OS X :) */flame*

Musím užnat že asi 90 % těch věcí umí právě MacOS. Když jsem to viděl poprvé, ani jsem nedýchal...

otaceni krychle je samozrejme neergonomicke, ovsem autor zapomel poznamenat, ze "krychle" se da posouvat ctrl+sipra leva/prava a to bych co do ergonomie rekl ze je uplne skvela funkce... takze posuzovat krychli jenom z pohledu ze muze byt videt cela... nesmysl, krychli hodnotim jako ergo+

Silicon Graphics O2 (za 400 000 kc v 1998) s 256MB ram a procesorem R5000 na 200MHz dovede v realnem case delat GL efekty na zive sbiranym videu, nebo ho texturovat na pohybujici se GL objekty.
Hura, PC pomalu zacina byt schopno toho, co je tady 10 let.

V kterým bazaru, prosím??

Jinak k tématu: a o to právě jde, před 10 lety to stálo 400 tisíc, dneska to stojí sotva 10...

K článku bych doplnil, že průhlednost lze zajistit už nyní i pomocí rozšížení Xorg zvané "Composite" (viz google) - v KDE 3.5.2 to funguje pěkně.

Pro ty, kteří by chtěli zkoušet XGL, tak bych doplnil jako varování, že zatím nepodporuje rozšíření Xinerama (či v případě TwinView se dva monitory berou jako jeden velký), takže jediná možnost je použít samostatné displeje (což mi moc nevyhovuje).

Je to prostě vývoj a je to tak správně. Já jsem nikdy nesnášel líně se překreslující okénka. A když už ve videokartě ten garfický výkon je, včetně spousty "zadrátovaných" efektů, tak proč jej téměř zadarmo nevyužít!

Za pár let si již nikdo nevzpomene, že v dřevních dobách PC někdo používal neakcelerovanou grafiku a těžkopádná a nepřehledná 2D okna, vršící se na sobě jako stohy papírů. 3D prostor je pro člověka mnohem intuitivnější než nepřirozené omezení na 2D.

neviem si predstavit nic lepsie (a intuitivnejsie) nez virtualne plochy.
pracum s nimi bez problemov a velmi efektivne - rovnako si mozem prepinat aj viac textovych konzol.
pokial ide o to posuvanie okien - to ma trapi najmenej. otvorim okno, raz si ho nastavim - a uz ho neposuvam.

Tak že něco je na tom jen tak pro srandu aby se ukázalo co to umi něco je fakt užitečný- třeba ty průhledný okna... (viz TV), cube

Ale hlavní výhoda - vzhledem k tomu, že to běhá akcelerovaně nezatěžuje to tolik CPU.... Způsobí to opravdu rychlý náběh oken odezva při spuštění konsole se snížila na 0 u firefoxe se to moc nepozna protože zatěžuje sám o sobě CPU.

Dobry den.Nainstaloval som vsetko ako je v navode http://www.novell.com/coolsolutions/feature/17174.html po restarte ma nepusti do KDE!!!Len tak v textovom rezime.Tam som cital neako Xserver neake problemy su s tym.Ale robil som to presne podla navodu ako je tam.To sa mi stalo uz 2 krat!!!!Prosim surne o pomoc moje ICQ - 246-795-799

Zapomnelo se na dulezitejsi a uzitecnejsi vlastnost. Kazde "okno" se definuje jako obdelnik umisteny v ose "z". Obsahy oken se vykresluji do textur oken bez ohledu na jejich viditelnost a celou logiku "viditelnosti" oken dela graficka karta. Vysledkem je rychlejsi prepinani mezi okny a usetreni pameti ve prospech aplikaci. Window manager toho pak nema tolik na praci. (snazil jsem se to napsat tak trochu pro kazdeho .. :-)