Pomalost GUI javy

18.1.2009 18:44 | Přečteno: 2216× | Jiné

Tak jsem na to přišel. Pomalost javy v GUI není skutečně chybou javy, ale asi Linuxu (či xorg).

Jako semestrálku na algoritmizaci jsem dělal kreslení grafu libovolně složité fce. Dělal jsem to v Linuxu a přišlo mi to strašně pomalé. Pak mi ve škole docházela baterka, tak jsem to zkopčil na flashku a v počítačové učebně to na Windows dodělával. Jaké bylo překvapení, že to tam běží snad 10x rychleji - žádné záseky při posouvání, zoomu ani vykreslování tečen pro každý bod. V Linuxu se to sekalo. Jak s compizem, s kde4 s efektama i bez efektů a bez compizu. Zkoušeno na 32bit ArchLinuxu a 64bit ubuntu s openjdk i sun-java - všude stejné. Na Windows XP ve škole, Windows Vista a Windows 7 doma naprosto plynulé - zajímavé. A co je zajímavější, na Linuxu je to nepoužitelné s vyhlazováním a na Windows to jede stejně rychle i s ním. Možná to bude tím, že na Windows je i GDI akcelerované grafikou, ktežto na linuxu to asi akceleruje tak velký ho*no.

       

Komentáře

[kouzer]

To je náhoda, zrovna jsem to samé zazamenal při používání jEditu.

[Jary]

Aby to nebylo nekvalitním adapterem/bridgem mezi Xorg a Javou.

[Petr "Glubo" Sýkora]

A co proti tomu, jakožto běžný uživael mohu dělat?

[Josef Kufner]

Šťouchat do programátorů, ať s tím něco udělají. Ideální nástroj na šťouchání je řádně vyplněný šek. V případě, že by to nepomáhalo, nech si jej vyplatit v drobných a použij ty.

[koroptev]

kdyz jsem mel c64 a nahraval veci z kazety, pomahalo modleni

[deda.jabko]

ja jsem v jave (v linuxu) psal bakalarku (editor diagramu), zadne optimalizace jsem nedelal a i na z dnesniho pohledu starem stroji (duron 1GHz a min nez pul giga RAM) to jelo vsechno naprosto plynule i pri docela slozitych schematech. kdyz jsem to pak zkousel na windows (xp) tak to zanechavalo obcas nepekne artefakty, takze to GDI taky nebude uplne super...

[podlesh]

Kvůli těmto problémům lze akceleraci přes Direct3D vypnout.

[Algi]

Podle mě nebude problém ani tak v Linuxu jako v Sunu. Ti pro Linux neudělali v tomto směru příliš kvalitní práci, proto je Java na Linuxu taková jaká je. Mám možnost srovnávat se všemi tremi systémy (doufám, že tam není gramatická chyba ). Na Windows je GUI vcelku dobré, používa-li se nativní look and feel. Při Ocean může být překreslování vcelku tragické (vyzkoušeno na Netbeans Platform projektu). Na Linuxu již bylo řečeno. Na Macu s nativním look and feel luxus. S Ocean docela špatné...

Rád bych tím apeloval na vývojáře Javovských aplikací, aby pokud možno nechávali výchozí Look and feel a to jest systémový. Na Macu je zapnutý standardně, na Windows a Linux si o něj explicitně řekněte. Je to dobré nejen kvůli lepšímu výkonu GUI, ale i kvůli systémové integraci... S ní mám obzvlášť na Macu dobré zkušenosti a dokázal bych poradit.

[kralyk z abclinuxu]

Windows je i GDI akcelerované grafikou

Nemyslím.

[kralyk z abclinuxu]

A zkoušels to na jiným hardwaru?

[podlesh]

Windows je i GDI akcelerované grafikou

Takto ořezané je to skutečně pravdivý výrok, akorát že nemá s rychlostí Swingového gui v Javě moc velkou souvislost.

[User682]

zdravim,

resil jsem podobne podrobneji pri psani editoru v jave na platforme Eclipse. 4 roky praxe s GUI na jave. Jinak jsem programator desktopovych komponent v jave.

Problemy jsou dva.

1) nespravne pouziti - v aplikaci mate neco, co jiz brzdi. Zpracovani dat. Anebo take treba neumite spravne pouzivat layouty a volat prekreslovani (staci prekreslit cast, nepackovat pokazde a tak....). Da se skutecne napsat rychla aplikace. Nekdy staci aplikovat pouze zmeny a dosahnete velkeho zrychleni. Ale toto jsou obecne zaklady pro psani jakehokoli GUI ci graficke aplikace.

Pocitejte s tim, ze to bude na 95% chyba u Vas.

2) na Windows je SWT o dost rychlejsi nez na Linuxu. V bugzile jsem videl, ze problem je v gtk knihovnach. Nove gtk knihovny by mely byt o dost rychlejsi, nicmene nejsou zakomponovany do SWT.

Idealne podtaktuje procesor/y a mrknete se co je pomale.

Jinak java na Linuxu (Swing je akcelerovane) pomoci OpenGL.

Osobne jsem zjistil prakticky behem roku a pul, ze za nejvice zpomaleni aplikaci si muze sam programator. Je to o algoritmech a strukturach.

Bohuzel vetsina programatoru neumi pouzivat vhodne struktury a algoritmy. Natoz nevi, ani jak funguji a jak se delaji GUI. Bohuzel vetsina lidi a asi se dobre pobavim v diskusi bude vedet, jak funguje do detailu javovy VM, napsali jiz nekolik VM implementaci, ale GUI umi akorat maximalne nahazet prvky na platno a tim to konci.

 

 

[Pavel]

Co to je ze techniku, podtaktuje procesor a mrknete, co je pomale? Na tohle snad mame profilery ne?

[User682]

Pouzijte co chcete, hlavni je vysledek. Naprosty souhlas, ze profiler je idealni reseni. Nebo zda to odladite pomoci tisku casu do stdout. Nicmene se mi dane osvedcilo, kdyz vidite, jak je aplikace rychla na pomalejsim stroji.

[Josef Kufner]

Idealne podtaktuje procesor/y a mrknete se co je pomale.

I když podtaktování procesor(ů) není špatný nápad (ukáže to celkový dojem z pomalosti), daleko lepší je použít profiler. Ten i ukáže kde přesně to drhne. Bohužel, s rostoucím výkonem HW se takovýmto věcem moc pozornost nevěnuje a pak to vypadá, jak to vypadá...

[Ladicek]

Bohuzel vetsina lidi a asi se dobre pobavim v diskusi bude vedet, jak funguje do detailu javovy VM, napsali jiz nekolik VM implementaci, ale GUI umi akorat maximalne nahazet prvky na platno a tim to konci.

To by byl tak trochu můj případ Zajímám se o programovací jazyky a překladače, ale rychlé GUI v Javě bych napsat nedovedl. Přitom ovšem bezpečně vím, že to lze: hraju si teď trochu s MPS a ve Windows XP na notebooku s nějakým Pentiem na 1,8 GHz a 512 MB paměti je GUI naprosto bezproblémové.

[User682]

No vidite. Ja mam zase problem, ze nemam cas zlomit projekt antlr.org = dostat se do stavu, kdy jsem schopen s tim delat a neco v tom rozumne kodit. Problem je cas.  A nejhorsi je zlomit filtrovani stromu/grafu.

Co se tyce tech GUI, tak se hodi si precist nejakou vetsi knihu. Nicmene je to o praxi. A idealni je natrefit na lidi, co to umi. Pak teprve zjistite, ze

clovek delal hodne veci hodne spatne a "mlatite hlavou o zed".

Asi nejvetsi problem je, ze lidi nevi, jak GUI nebo treba i database funguji a ze umi neco vice nez je v ukazkovych prikladech. Hodne casto mam pocit, ze najdete sice dost ukazkovych prikladu, ale chybi tam nektere bezne potrebne veci.

Osobne jsem vcelku dost dlouho dobu ignoroval dulezitost layoutu. I kdyz vse napsane nejak fungovalo a stiznosti nebyly. Byla to vcelku chyba.

Hodne dobra praxe je napsat si editor - to je slusna skola. Nebo si napsat GUI pro nejaka metadata - kde doslova dostavate i data o poctech sloupcu, vnorenych komponentach.

Co se tyce experimentovani s parsery a generatory, tak si myslim, ze ta prava skola je, pokud popisete vetsi gramatiku. Ona kakulacka je zajimava uloha nebo vyparsovani jednoho souboru s linearni slozitosti (data v radcich), ale slozite a prakticke to moc neni. Osobne si myslim, ze ta prava uloha, je pokud ze streamu zdrojaku do nejakych dalsich streamu.

Jinak diky za typ - MPS. Ukladam do bookmarku. Osobne si drzim ale generatory castecne od tela. Jsou super, ale moje prace je vetsinou o tom, ze danou vec musim potom nasledne pouzivat a upravovat. Hlavni prace je spise v aplikacni logice a na tom se nejvice usetri.

Jinak generatory maji urcity potencial. To ano. Jenze co nejak nejede a nikdy nejelo, ze by nekdo zacal delat misto 1 formulare denne 20 a vice generovanych formularu a dostal za to temer primo umerne zaplaceno. To bohuzel moc nefunguje. Alespon, co jsem videl. Osobne se nam spise osvedcila metoda nejakeho abstraktniho modelu a zbylych 5-10% doprogramovat konkretne = vetsina casu.

 

 

 

[deda.jabko]

imho zapaseni s ruznym parsery a jejich generatory je pri navrhu (programovaciho) jazyka docela okrajovou zalezitosti.

jak jsem tak zbezne proletel ten clanek o MPS, tak to vypada, ze se tu nekdo snazi opet objevit kolo... myslenky maji dobre... ale musim si rypnout: uz pres padaset let je tu LISP a pres tricet let Scheme s jejich systemy maker... ktere resi vetsinu nastalenych problemu a o poznani elegantneji...

[Ladicek]

Gramatiky a parsery nejsou složité. Něco už mám v tomhle odprogramováno a generátory nevidím důvod používat. I když ANTLR je asi jediný, který by používat mělo smysl.

S tím Lispem je to pravda. Napůl. Všichni víme, že programovací jazyky pomalu konvergují k Lispu , ale kolik lidí ho opravdu umí používat? Já vím, Paul Graham a tak… Práce s jazyky je v něm mnohem snazší, ale MPS je určené pro normálnější lidi. Nebo, jinak řečeno, pro lidi, kteří (ještě) nejsou schopní tak dobře abstrahovat.

[User682]

ok, pojdme se bavit o __praktickych__ vecech a implementacich.

Resil jsem par uloh. Ozvete se mi na mail.

Pridam par veci, co shanim a zajimalo by me, kam jste v tomto dosel. Par veci jsem prosel, ale v par nemam jasno + cas. A zkusenosti se v tomto spatne a dlouze shani.

0) z database se da vygenerovat GUI. Se vsemi zakladnimi operacemi nad nim (ukladani, vlozeni, mazani). Pomoci klicu v databasi dostanete i nejake informace o ostatnich formularich nebo o zobrazeni ciselniku. Neco castecne o navigaci.

1) rozparsujete nejaka data na AST strom. Nicmene strom potrebujete transformovat na nejaky jiny strom. Ten strom uz nemusi byt gramatika, ale nejaka struktura - graficky vystup ci objekty. Nebo, jak z formulare s daty udelat aplikaci - reverse.

2) oprava dat pomoci gramatiky  + podobnost retezcu. umisteni elementu ve stromu. Jak spachat GUI a jak popsat nalezene chyby - sgrupovat je.

3) mam data, ktera obsahuji treba 3 typy gramatik v sobe (aplikace, sql dotazy, html) a chci to prevest na samostatne proudy, kdy jeden proud je jeden typ gramatiky.

4) anlr - stringtemplate - pouzival jste ?

goldenfish at linuxsoft dot cz

[Ladicek]

Jak jsem říkal, zajímám se o programovací jazyky a překladače, takže spíš v tomhle oboru mám nějaké zkušenosti. S tím, co potřebujete, vám asi nepomůžu, ale zkusím drobný komentář k těm bodům, co jste napsal.

0: je užitečné zavést jmennou konvenci. Pracoval jsem nějaký čas na projektu, kde jsme používali (resp. framework vynucoval) konvenci pro názvy cizích klíčů ve tvaru XNÁZEV_NAVÁZANÉ_TABULKY__XNÁZEV_PRIMÁRNÍHO_KLÍČE_V_NAVÁZANÉ_TABULCE, a tím třeba dostanete tu navigaci. Samozřejmě musíte udržovat v paměti model databáze.

1: to vede na generování kódu nebo na visitor, více nebo méně přímočarý podle toho, jak spolu zdroj a cíl korespondují. Pro některé situace je skoro lepší nepoužívat vlastní formát, ale vzít už existující jazyk. V Javě je docela dobrá volba Groovy, kvůli jeho konceptu builderů – koukněte třeba na Swing Builder. Opačná transformace – jo, tak to hodně štěstí.

2 a 3: to jsou dost zajímavé problémy, některé možná i výzkumného charakteru. Řadu z nich řeší vývojáři každého lepšího IDE. Reprezentaci chyb je nutně třeba řešit při inkrementální syntaktické analýze, protože většinu času zdroják není syntakticky v pořádku. V češtině jsem o tom četl tenhle text, jsou tam i odkazy na další zdroje. Jak se řeší reprezentace textů v různých jazycích v jednom souboru netuším, ale typický příklad je třeba HTML+CSS+JavaScript v jednom souboru.

4: nikoliv, znám to jenom teoreticky.

[Ladicek]

K té knížce o javovském GUI, můžete doporučit nějakou konkrétní? Já jsem sice momentálně webař, ale stejně.

[Deleted [8409]]

Nedá mi to, musím oponovat.

Mluvíte o tom, jak si programátoři můžou za pomalost GUI sami, a je použitím špatných algoritmů. Tyto argumenty beru jako univerzální odpověď na cokoliv. Navíc podle vašeho tvrzení jsou Windows C++ programátoři úplní machři, kteří umí dělat superrychlé GUI.

Osobně vím, že jde naprogramovat rychlé GUI pod Windows a pod Linuxem (jiné OS jsem nezkoušel), ale svádět veškerou pomalost na programátory je nesmysl. Je jasné, že pokud budu v handleru události onPaint() počítat fraktály, tak to překreslení asi rychlé nebude, ale tento blog byl pokud vím o vykreslení průběhu nějaké libovolné funkce (berme jako testovací třeba sin(x) ).

Takže otázky, které bych si pokládal budou tyto: Kolik tlačítek a dalších nesmyslů můžu u takto složitého úkolu potřebovat? Kolik zabere vygenerování cesty pro tak jednoduchou funkci ? Pokud se překreslování seká, znamená to, že současná sestava nezvládně nakreslit průběh funkce sin(x) 30x za sekundu?

[alblaho]

Pod to se můžu podepsat.

Já bych u té Javy viděl problém i někde jinde. Myslím, že uživatelský komfot můžou neblaze poznamenat lagy způsobené GC. Nemám to nijak ověřené (momentálně nepoužívám žádný destkopový program v Javě), ale myslím, že stop-the-world GC může program zaseknout klidně na víc než 0.1 sekundy.

Kdysi na Windows jsem používal JEdit, považuju ho za dobrý program. Na Linuxu jsem ho zkoušel, ale nějak hnusně renderoval písmo, takže jsem přešel na Gedit.

[Heron]

Nemám to nijak ověřené (momentálně nepoužívám žádný destkopový program v Javě), ale myslím, že stop-the-world GC může program zaseknout klidně na víc než 0.1 sekundy.

O tom už se tu diskutovalo též hodně. Myslíš, že 0.1s jednou za půl hodiny (no i kdyby jednou za minutu) je pro toho uživatele nějaký problém? Obzvláště na když se drtivou většinu času čeká na uživatelský vstup? Pokud GC proběhne mezi dvěma stisky kláves (což se stihne), tak to stejně nepozná. Dokonce ani na animaci (např. real-time vykreslování grafů) není GC a stop-world nijak zvlášť patrné (fps dejme tomu 25, tj 40ms, tzn vypadne jeden až dva snímky, toho si ani nevšimneš - nebo to budeš přikládat výpadku sběru dat ).

[Ladicek]

Já tomu nerozumím, ale to zřejmě spousta lidí. JEdit nebo věci od JetBrains s rychlostí GUI nemají problémy. Osobně jsem přesvědčen, ale nemám pro to důkazy, že to je prostě dané Swingem, který je čistá Java. Měli by se u Sunu pochlapit, celý Swing a JavaFX zrušit, koupit Nokii a oficiálním GUI toolkitem udělat Qt Jambi

[Josef Kufner]

To snad radši ani ne... ještě by se zpomalilo Qt na linuxu.

[Ladicek]

To se snad děje i bez toho.

[User682]

Oponujte, klidne. Psal jsem toto:

>>Pocitejte s tim, ze to bude na 95% chyba u Vas.

Vychazi mi to z praxe - statistika. Neni to pouze universalni odpoved.

Bez konkretni implementace (zdrojaku) jsme tu nahrani asi vsichni.

[Jardík]

Moment, tak já vám je sem někam nahraju.

[Jardík]

Příloha:

• GrafFunkce.tar.bz2 (160026 bytů)

Tak tu to je.

Dílo, ani dílo odvozené nelze šířit pod žádnou GNU licencí, jinak si s tím můžete dělat, co chcete.

[finn]

Nemůžu si pomoct, ale u mne je to naprosto plynulé: Gentoo, dev-java/sun-jdk-1.6.0.11, Sempron 2200+, 1GB paměti.

[Jardík]

Já mám taky sun-jdk 1.6.něco, Ubuntu 9.04 x64 a ArchLinux x32, Intel Core 2 Duo @2GHz, 3GB RAM, Grafika Intel X3100 (ovladače 2.5 i 2.4).

[Algi]

Obávám se, že tam přece jenom bude něco trochu shnilého. Když měním velikost okna, tak se občas nevykreslí levá část okna s tlačítky... Může to být pochopitelně bug Javy, ale abych byl upřímný – ještě se mi nic takového nestalo...

Jinak pěkná aplikace; až se člověk krapet zastydí, že nic takového nenapsal

[Jardík]

No oni ty tlačítka jsou na Linuxu taky nějaký podělaný, GTK je zkoní, když se zapne javovské metal téma, tak jsou správně - ale pomalé je to stejně.

[User682]

zdravim,

jede to jak brus. Je to hodne rychle. Zatez CPU 15-30% odhadem - horni hranice v IDE podle funkci. Testovaci stroj Lenovo R400 a posledni stabilni JDK 1.6. Kernel 2.6.28. Intel ovladace grafika - 2.3.x.

Na vice se mrknu behem par dni - napisi pripadne soukrome. Jsem jeste ted v zamestnani a casove mam posledni dobou hodne nabito.

[zde]

Anebo take treba neumite spravne pouzivat layouty a volat prekreslovani (staci prekreslit cast, nepackovat pokazde a tak....). Da se skutecne napsat rychla aplikace. Nekdy staci aplikovat pouze zmeny a dosahnete velkeho zrychleni. Ale toto jsou obecne zaklady pro psani jakehokoli GUI ci graficke aplikace.

Můžete doporučit nějakou otevřenou aplikaci, kde je to podle vás implementováno správně, a která je čitelná? Pokudmožno nejen dialogy, ale i nějaký canvas s interaktivní grafikou. Díky.

[podlesh]

Abych to uvedl trochu na pravou míru (tedy doufám): pro akceleraci 2D grafiky (tedy i Swingu) se v sunovské javě používá Direct3D nebo OpenGL.

Direct3D akcelerace existuje již delší dobu (pokud vím tak od 1.4) a je defaultně zapnuta (dá se vypnout pokud jsou problémy, především kvůli některých driverům).

OpenGL akcelerace byla přidána v JDK 1.5 a defaultně je vypnuta.

[Jardík]

U mě to nějak nefunguje. Přidal jsem ten parametr a nic to nedělá, když dám velké True (debug), tak to taky nic nevypíše. A aby si to nestěžovalo (neznámý parametr), musel jsem ten parametr prefixnout -J

[Andrej Herceg]

Mne to funguje v "Java(TM) SE Runtime Environment (build 1.6.0_10-b33)" (pri True sa vypíše "OpenGL pipeline enabled for default config on screen 0"), ale aj keď nezapnem OpenGL, vytaženie CPU je okolo 20-30% (vlastne s OpenGL je o niečo vyššie). Občas sa ale stane, že to zrazu začne zaťažovať procesor na 100% (stáva sa to hlavne vtedy, keď sa zrazu začne zle vykreslovať tá ľavá strana s tlačidlami).

Občas to (pri zmene veľkosti okna) vypíše niečo ako:

Exception in thread "AWT-EventQueue-0" 320java.lang.ArrayIndexOutOfBoundsException: 156
        at graffunkce.Graph.paintGraph(Graph.java:496)

0.025   at graffunkce.Graph.paintComponent(Graph.java:620)

0.016736401673640166    at javax.swing.JComponent.paint(JComponent.java:1027)

(tie čísla sú tam mierne rozhádzané, takže asi sa to vykonáva súbežne vo viacerých vláknach).

Inak ak tam nie je žiadny graf a potiahnem tú plochu pomocou myši, tak to píše

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at graffunkce.Graph.mouseDragged(Graph.java:337)

(a neviem čo všetko sa tam vyhodnocuje, ale aj keď tam nie je graf, zataženie je takmer rovnaké, ako vtedy, keď sa graf zobrazuje).

[Jardík]

Já sem dal asi tu starší verzi, je tam chyba v mouseDragged(), chybí tam ošetření, jestli je nastavená fce. A to při změně velikosti okna mi dělá občas taky a vůbec nemám páru proč. Ve více vláknech by to běžet nemělo, teda alespoň já tam víc vláken nevytvářím, leda že by sám swing, což by možná mohl být ten problém.

[Jardík]

Už jsem to našel, java mi zavolá překreslení sama po změně velikosti před tím, než zavolá componentResized (která patřičně realokuje pole), což je nějaké divné

[Ladicek]

Ve více vláknech by to běžet nemělo, teda alespoň já tam víc vláken nevytvářím

Takže děláš výpočty v EDT? Aha, hm, no, jasně

[Jardík]

Cože?

[Andrej Herceg]

Event dispatching thread

[Jardík]

Jen tak jsem to proběhl ... to jako vadí, že dělám výpočny např. v componentResized()? To to spustí v novém vlákně a pak třeba paintComponent() může běžet současně? To by byl hnus.

[Ladicek]

V tomhle tic-tac-toe prográmku nejspíš ne, ale provádění časově náročnějších operací (řekněme delších jak desetina vteřiny) v EDT je prakticky Zakázáno(TM). Koncept EDT, pokud vím, používají skoro všechny GUI toolkity.

Jinak, co je hnusnýho na komunikaci mezi dvěma vlákny? Hnusný je roubovat céčkovské formátování kódu na Javu (jedna z mála věcí, které mi vadí na Wicketu)

[Jardík]

Narážíš na mé formátování kódu? Mně se zas hnusí to výchozí formátování, co mi vnucuje netbeans - mít otevírací závorku pláclou hned za if, while atd. je podle mě nepřehledné (ještě že jde netbeans pŕenastavit).

[Ladicek]

Nepřehledné možná pro toho, kdo odsazuje jednou mezerou, fujtajbl

[Jardík]

Já neodsazuju 1 mezerou ale tabulátorem...

[Ladicek]

Jo, mně to včera nějak blbě zobrazovalo… i když GrafFunkceApp.java i GrafFunkceView.java obsahují řádky odsazené mezerami, asi generovaný kód.

S takovou ovšem nechápu tu potřebu uvozovací závorky na novém řádku, akorát zabírá řádek navíc. No, to je jedno.

[Jardík]

Jo, ty 2 soubory generoval netbeans.

[happy barney]

fuj, za odsadzovanie tabulátorom vešať do prievanu

[Ladicek]

1 tabulátor = 1 bajt. 4 mezery = 4 bajty. And bytes cost money!, jak říká Cal Henderson Jinak ovšem souhlasím.

[kralyk z abclinuxu]

já přeci jen trochu šetřim; odsazuju jen 2 mezery = 2 bajty

[Petr "Glubo" Sýkora]

Stále jsem nepochopil -- proč?

[podlesh]

To se mi zdá nějaké podezřelé, to -J. Jak to spouštíš?

[Jardík]

java -jar program.jar -J-Dsun.java2d.opengl=True. S java -jar program.jar -Dsun.java2d.opengl=True to akorát vypíše "invalid argument"

[podlesh]

No jistě, musíš to dát před ten spustitelný jar. Na rozdíl od GNU/linuxové konvence se nemohou přepínače a argumenty jen tak míchat.

java -Dsun.java2d.opengl=True -jar program.jar

[Jardik]

Could not enable opengl pipeline for default config on screen 0

[podlesh]

No vida, není OpenGL. Pak to má být pořádně akcelerované :-/

[Jardík]

Ale OpenGL normálně je. Direct rendering je On a compiz taky normálně běží, glxgears taky pár set (380) FPS ukážou a gltron jede. Kdyby to alespoň vypsalo, proč že to nejde zapnout.

[oroborus]

Jako semestrálku na algoritmizaci jsem dělal kreslení grafu libovolně složité fce.

 Aj ja by som chcel robit taku semestralku:)

[Jardík]

Příloha:

• DVDReader.zip (20677 bytů)

Nevšímejte si tohoto komentáře, potřeboval jsem uploadovat program pro Mac, který bude číst ISO Level 3 DVD se soubory > 4GB, Mac OS to neumí, tak jsem si musel vytvořit program na čtení přímo ze zařízení.

Pokud má někdo zájem o info, tak zde je vytržené z kontextu z tohoto fóra.

Tak už je zítra Přeloženo a zdá se, že to funguje. Takže nejdříve popis ISO Level 3 a pak info, jak s tím programem pracovat.

ISO do Level 2 může mít maximálně soubory do 4GB, ISO Level 3 je do jakési míry kompatibilní a to do takové, že soubor > 4GB je rozdělen na 2 části a ty jsou uloženy jako 2 samostatné soubory se stejným jménem a první z nich má nastaven "atribut", že to není poslední část a druhý, že je (a Mac je interpretuje jako jeden a vezme v úvahu ten druhý (takže ten menší) a proto ta chyba).

Vložíte DVD Iso Level 3 (pukud je tam udf filesystém, tak to radši nezkoušejte, se mi to trochu zacyklilo ). Příkazem mount v terminálu zjistíte označení zařízení mechaniky (v mém případě /dev/disk1). Příkazem "sudo su" se přihlásíte jako root a příkazem "unmount /dev/disk1" odpojíte DVD (jinak to zařízení nepude programem otevřít). Spustíte program "./DVDReader". Zeptá se vás na jednotkum, dejte mu ji (/dev/disk1 enter). Načte se struktura DVD a ukáže se výzva k zadávání příkazů. Příkazy jsou:

help - seznam příkazů
exit - ukončit DVDReader
tree - zobrazí adresářovou strukturu DVD (hvězdičkou jsou označeny soubory složené z více částí a v seznamu se objeví vícekrát)
cp - zkopíruje soubor. Parametry jsou "adresář/a/jméno/na/cd.mkv" a "/Jméno/na/disku.mkv". Lze kopírovat pouze soubory, né adresáře. Kopírování může trvat dlouho, čte to po sektorech (2048 B).

Zdrojáky jsou napsané prasácky. A netuším, jestli z toho gcc vytvořil 64bit nebo 32bit binárku, takže když vám nepůjde, zkuste si to zkompilovat.