Proč? II (XGL)

22.4.2006 21:59 | Přečteno: 1670× | Linux | poslední úprava: 22.4.2006 22:38

Po mém posledním zápisu mi to nedalo a přepnul jsem se do Ubuntu DD 6.06, kde mam nastavený XGL server.

Připravil jsem opět pár záznamů, myslím že to vydá za spoustu zbytečných slov :)

Program nautilus

Program gthumb (standardní prohlížeč obrázků)

Program gqview

Program firefox

Jen poznámka: Samozřejmě to tak hrozné v normálu není, když natáčím, tak mi zaznamenávání zabere asi 30-50% CPU, ale i tak je to dost otřesné, rozhodně podle mého názoru horší, než bez XGL, skrolování ve Firefoxu je o dost trhanější, mimochodem firefox se trhá mnohem víc, ale protože při svém resizu asi zvednul prioritu, tak mi zaznamenávání vynechávalo snímky a tak to nevypadá tak strašně jako ve skutečnosti.

Poznámka č. 2: Bohužel jsem nemohl otestovat jak se chová exhibit, který je napsaný tuším v EFL, nebo ETK, protože v Ubuntu tento balík není a není jednoduché ho tam dodat.

Poznámka č. 3: Videa jsem překódoval, takže mají cca od 1,6 do 3,5MB.

       

Komentáře

[David Watzke]

Ten gThumb... docela mazec

Btw, 36 sekund a 12 MB? Děláš si srandu? Mohl jsi to alespoň projet MEncoderem

[Thunder.m]

Napiš mi příkaz pro překódování a já to rád udělám :) Nechtěl jsem to v reálu zaznamenávat do mpeg4, protože to žralo asi 90% CPU.

[David Watzke]

Třeba

mencoder -ovc xvid -xvidencopts bitrate=500 \
-oac copy -o output.avi input.avi

[Thunder.m]

Tak to mi vypisuje nějakou chybu, asi nemam mencoder zkompilovaný s podporou xvid, ale jen divx, zkusil jsem to pomocí divx codecu, ale ten mi zase zkazil barvy, zkouším to ještě přes transcode, chvilku to bude trvat.

[David Watzke]

Zkus raději lavc...

mencoder -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=500 \
-oac copy -o output.mpg input.avi

[Thunder.m]

Když já mam transcode fakt nejraději, vždy mi dával lepší výsledky, než mencoder, nebo cokoliv jiného a nepadal :)

Použil jsem příkaz: "transcode -y xvid4 -i input.avi -o output.avi -Z 512x384 -w 500 -b 128 -s 2 -I 5 -C 1 -G 1.1"

Tohle používám pro převod DV videa do DivX, takže tam můžou být některé parametry zbytečné :)

[azurIt]

no mas asi pomaly HW ;) u mna to nic take nerobi

[Thunder.m]

Athlon 64 3400+, 1024MB RAM, nForce 4 deska, GF 6800GS 256MB, HDD 200GB. To je dnes už pomalé?

Tohle je čistá instalace Ubuntu a i ve vlastním Debianu mi to dělá rok (od začátku, některé aplikace víc, některé míň), jen mě to postupně začíná dost štvát, protože jsem spoléhal na to že XGL to odstraní. Aplikace v QT to nedělají, ale mě prostě KDE nesedne...

[xxxxxxxx]

musis mit nekde chybu. mam a64_3000+ a tohle mi to proste nedela :-/

[Thunder.m]

Můžeš to nedělání zaznamenat? Jakou používáš distribuci?

[xxxxxxxx]

je to tam trosku mirne znat, ale urcite to neni tak strasidelny jako u tebe. mam mandrivu a kde. zkousel jsi tam dat nejaky zakladni skin?

[Thunder.m]

GTK 1.X (starší aplikace jako Mozilla Suite) se chovají trochu líp. Tohle je základní skin pro Ubuntu. Bez XGL je to trochu lepší, viz můj první příspěvek. KDE aplikace jsou mnohem svižnější, než ty psané v GTK, ale stále to není ono :)

[xxxxxxxx]

mas multimedia kernel?

[xxxxxxxx]

ten by mel mit o dost lepsi odezvu u aplikaci

[David Watzke]

Copak to je?

[xxxxxxxx]

kazdopadne mm kernel v me distribuci by mel mit ///teoreticky/// 10x lepsi odezvu nez normalni 1k kernel

[David Watzke]

Moment, mm je zase něco jiného, ne?
[N] sys-kernel/mm-sources (): Andrew Morton's kernel, mostly fixes for 2.6 vanilla, some vm stuff too

[Thunder.m]

To je joke, nebo ani ne? Jak to mohu zkusit? V Ubuntu mam distribuční jádro, na svém Debianu si kompiluji jádra sám (teď tam mam 2.6.16.1).

[xxxxxxxx]

prekompilujes jadro, vsechno nechas stejny, jen tam zmenis nejakou frekvenci z tisice na sto. ted takhle brzo poranu sem to nenasel ani v menuconfigu jestli to bude mit nejakou souvislost s tema dvanacti dvanactkama co sem vcera vecer vypil

[hydrandt]

Řekl bych, že to tu souvislost mít bude

[Thunder.m]

Aha, o tomhle vím, používám tam myslím 1000, no zkusím 100.Ubuntu taky používá 1000.

[Thunder.m]

Jdu teda překompilovat kernel :)

[Thunder.m]

100 HZ is a typical choice for servers, SMP and NUMA systems with lots of processors that may show reduced performance if too many timer interrupts are occurring.

1000 HZ is the preferred choice for desktop systems and other systems requiring fast interactive responses to events.

Mam tam 1000, opravdu myslíte, že mi 100 může pomoct?

[Prcek]

Podle toho popisu bych nechal 1000 , ale treba tomu nekdo rozumi vic a vysvetli to.

[David Watzke]

Přesně tak... lot of processors tu zrovna nemám

[Prcek]

jj je tam takova moznost - vybira se tam nejaka frekvence odezvy - myslim ze je tam i napoveda "Low latency desktop" a "Server". Ale ted nejsem v Linuxu a nemuzu to overit :-/, ale urcite se tam neco takoveho nastavuje. Jeste by na to mohl mit mozna vliv nejaky ten Scheduler, ale v tom uz se nevyznam

[xxxxxxxx]

IMHO cim mensi cislo frekvence, tim casteji se aplikace dostanou k prociku a tim casteji se budou vykreslovat okna. IMHO

[David Watzke]

Uhh... IMHO je to přesně naopak

[David Watzke]

Tak jsem to zkusil, vanillková 2.6.17-rc2ka...

V Processor type and features jsem zvolil Preemption Model (Preemptible Kernel (Low-Latency Desktop)) ---> a Timer nastavil na 100 Hz a je to skutečně o něco lepší - Qt-based aplikace jsou teď úplně super a třeba Bon Echo se taky chová líp

[xxxxxxxx]

je videt, ze to me IMHO bylo IMHO dobre

[KS]

No vnitřek okna má pomalejší odezvu. Nikdy mi to ale nevadilo. Obvykle okno otevřu, resiznu a několik dní s ním třeba vůbec nehýbu.

[Milan Hejpetr]

To je zajimave. Nikdy jsem teto veci neprikladal vetsi vyznam. Asi to bude tim, ze uzivatel meni velikosti oken velmi zridka, takze spousta z nich si toho ani nevsimne.
Ale ted jsem to tedy pozorne vyzkousel - opravdu je to nekdy neprijemne pomale v zavislosti na aplikaci. Zdaleka nejhure se chova SeaMonkey (1.0.1). Mozilla 1.7.13 je celkem v pohode (GTK1).
Jenze jak jsem psal na zacatku. Jak casto menite velikosti oken ? :)

[Bluebear]

Taky jsem se nad tím nikdy předtím nezamýšlel, ale na desktopech, kde pracuji delší dobu, automaticky vypínám zobrazování obsahu okna při překreslování. Asi mi to taky podvědomě leze na nervy.

[Jindřich 'GoldenShit' Plešinger]

   Resize oken v GTK+ a jejich pomalá odezva je problém který se tu již rozebíral. Je to fakt, a není nic složitého, že v tomhle je Linux zaostalý a stále se říká a čeká, že nová verze GTK+, nové XGL, nové cairo, nové ... to vyřeší. A ono noc. Já jsem si to vyřešil tak, že jsem si nastavil pro resize nevykreslování obsahu okna a vykresluje mi to jen rámeček. Stačí podotknout, ře win32 aplikace ve Windows se takto hloupě nechovají. Asi to bude také tím, že se k jádru jejich instrukce a popis zobrazení nedostává skrz 358 vrstev.

[Kníže Ignor]

358 podruhé (viz hledání)

evidentně Plešingerova konstanta pro hodně moc

[Thunder.m]

Docela zajímavé je podívat se na Office 2003, ten totiž taky používá resize, kdy se nezobrazí obsah okna, asi zjistili u Microsoftu, že je to docela pomalé :)

V tomhle příspěvku jsem chtěl podotknout, to že mě to trápí a když někdy něco někomu v Linuxu ukážu, tak se mi v tomto případě skoro vysmívá. Zároveň jsem chtěl ukázat že to někde jde i tak skvěle rychle (exhibit) a dokonce v Linuxu :)

[Jindřich 'GoldenShit' Plešinger]

   Taky bych byl rád, kdyby překreslování obsahu okna při změně velikosti fungovala normálně. Bohužel tomu tak není. Proto zatím používám nevykreslování obsahu. V operačním systému Windows XP a aplikacích používající win32 nemám problém. Horší je to u frameworků.

[Jan Zahornadsky]

Tak bych byl rád. Navrhni tedy řešení. Kreslení okna samozřejmě něco trvá, co budeš dělat onu chvilku? Buď zasekneš procesy jako Win32 a celé to nakreslíš až se aplikace uráčí překreslit, nebo řekneš aplikaci "hele, máš jinou velikost okna, něco s tím udělej" a necháš ji v tom jejím vlákně běžet dle libosti. První řešení má průser, že pokud nějaká aplikace se při kreslení zasekne, zasekne se celý subsystém Win32. Druhé řešení má průser, že aplikace se k této zprávě může dostat docela pozdě (zpracovává zatím jiné zprávy, X server kreslí i mezistavy apod.) ale je stabilnější. A konec konců, asynchronní vykreslování je přeci jen návrh hodný tomu, abych si bez výčitek mohl říct, že systém umí multitasking.

Život je otázkou priorít. Windows (aspoň desktopové verze, k serverové jsem žádné moc nepřičichnul) je od začátku navržen tak, aby v "běžném uživateli" budil dojem rychlosti. Pro to se používají někdy opravdu programátorsky nechutné hacky. Třeba okno, které je označené má automaticky větší prioritu. Tedy pokud sekretářka pustí výpočet nějakých maker v excelu a zatím si hraje solitér, tak ty makra trvají sakra dlouho, ale jí to nevadí. Solitér jde úplně plynule :-P

[Jindřich 'GoldenShit' Plešinger]

   Myslím si, že problém je v GTK+. Tuto knihovnu mám rád a byl bych moc a moc pro, aby se rychlost GTK+ maximálně urychlila. Kupříkladu u knihovny Motif jsem jediný problém nezaznamenal. Bohužel ji i jeho OpenNástupce komunita zavrhla a do popředí zájmu se dostaly velcí nenasytní a pomalí.

[Thunder.m]

Tomu se mi nechce věřit, proto jsem uvedl ve svém předchozím blogu ukázku z resize aplikace napsané například v ETK, tam k podobnému mazání a pomalému překreslování nedochází a stálě mě zajímá proč :)

[Jan Zahornadsky]

Možná viz jednu velmi známou diskusi (ale osobně doufám, že ji někdo smazal ) o tom, proč je Windows 95 rychlejší než linux (nebo jak to bylo).

Protože, pro tisíc a jeden důvodů. IMHO je docela důležité, aby open source aplikace poskytovaly programátorský komfort. Open source je jedna z nejlepších věcí na světě, pokud člověk studuje informatiku (vždyť Linux vznikl jako dizertačka nebo něco takového, ne?) Linux je velmi dobrá OS implementace UNIXu. To je taky fajn, protože UNIX má mnoho velmi dobrých myšlenek, které bych rád viděl i jinde.

Ale linux není něco, co by mohlo konkurovat Windows, jak si tady mnoho lidí myslí (v pravém slova smyslu). Windows je od začátků navrhován pro to, aby dodal uživateli pocit jednoduchosti, rychlosti a přitom profesionality. To se mu daří. Ale návrh je hrozný (viz ty někdy až nechutné hacky). A mně se Windows programy píší (pokud nepoužívám nějaký framework) o mnoho hůř, neposkytuje mi takový programátorský komfort.

[Lukáš Zapletal]

Program si nemůže zvýšit prioritu, pokud neběží pot účtem roota. Což by Firefox neměl

[stativ]

Teoreticky myslim muze pomoci priority inheritance (odvozovani priorit).

[luu]

No takze rek bych ze xgl v tvem pripade jeste defakto nevidels. Mam Ubuntu Dappera 1.7 Celer Gf4 TI a 512 RAm a frci to veeelmi svizne. Mas nekde hodne velkou chybu.Ono otaceni oken,vykreslovani oken prohlizece to je mazac ta rychlost.Takze otazka nema byt proc XGL ale proc mi to jede tak naprd.

[Thunder.m]

Nevěřím :) Prosím hoď někam videa, jak je resize těch aplikací, které jsem zde uvedl rychlý a bez hnusného překreslování, pak uvěřím a začnu hledat chybu (protože jsem zatím zkoušel Korrorru, nebo Ubuntu 6.06, nebo opensuse a všude mi to dělalo to samé).

[Ladislav Jancik]

A nemuze byt vadna graficka karta ??

[Thunder.m]

Zkoušel jsem to asi na 4 počítačích :)