Plány pro vývoj GTK+ 3.0

Federkiel.wordpress.com píše o plánech pro vývoj GTK+ 3.0, které byly prezentovány na GTK+ Hackfest 2008 (PDF). Mezi hlavní plánované změny patří předělání systému témat (skinů) a animací, zlepšení integrace do operačních systémů a přidání nového standardního Canvas.

15.3.2008 20:03 | David Watzke | Zajímavý článek

Komentáře

[Michal Fecko]

Ja by som tie plany upravil...
1. Upravit rychlost GTK
2. Vykaslat sa na skiny/animacie a popracovat opat na rychlosti GTK

[Jirka]

Znáte to "staré Klingonské přísloví"?

"Chceš-li optimalizovat. Zamysli se nad tím! Chceš-li i poté optimalizovat, tak se na to vykašli."

[J. M.]

To se bohužel nikdy nestane. Zlepšení rychlosti je pořád zoufalé přání č. 1 prakticky ve všech diskusích o GTK+, ale vývojáři GTK+ na to celých 5 let, co existuje řada 2.x, reagují výhradně tím, že GTK+ vylepšují novými a novými vlastnostmi. Když se zeptají, co ještě nového by lidé chěli, pokaždé je odpovědí jednohlasná smršť volání „RYCHLOST!!!“, na což vývojáři GTK+ pokaždé odpoví „dobře, máte to mít – v nové verzi přidáme nové vlastnosti a funkce“. Samozřejmě vlastnosti a funkce, které celý toolkit výrazně zpomalí. Po pěti letech vývoje je GTK+ 2.10 pomalejší než kdy předtím. Každým rokem se rychlost GTK+ GUI zpomaluje a zpomaluje, což je dáno i těmi novými motivy vzhledu, používajícími Cairo, které jsou čím dál hezčí a hezčí... A pomalejší a pomalejší. Pamatuji si, jak jsme nadávali na strašnou pomalost GTK+ 2.0-2.6 v porovnání se starým (a dnes neuvěřitelně rychlým) GTK+ 1.x, ale co bych dnes za to dal, kdyby současná GTK+ GUI byla aspoň tal rychlá, jak byla v raných dobách dvojkové řady.

[freshmouse]

zoufalé přání č. 1 prakticky ve všech diskusích o GTK+,

Je ovšem třeba říct, že na GTK si nejvíc stěžují ti, co nejvíc nenávidí GNOME a GTK aplikace by stejně nepoužívali.

[J. M.]

Jsi si tím jistý? Mně třeba se GNOME 2.x už dlouho hrozně líbilo (ten design GUI je velmi dobrý), ale celé roky jsem používal KDE (které je podle mě z hlediska návrhu GUI hodně amatérské) jenom kvůli rychlosti. A mám dojem, že takových tady bylo víc. Až teď to fiasko s KDE 4.x mě konečně přimělo přejít do GTK+ světa.

[freshmouse]

Dobrá, tebe z toho odečítám. Nicméně dojem (a myslím, že správný), že nejvíc na nějakou věc (a zejména software) nadávají vždy ti, co by tu věc stejně nepoužívali, mám stále.

A fakt jsi přešel? Super.

[Josef Kufner]

Mě si škrtni taky. Gtk2 používám, celkem dobře se pro něj programuje, ale jakmile bude KDE 4 použitelné, tak se k němu vrátím -- opustil jsem KDE 2 právě pro příšernou lenost a Gtk teď opustím pro technologickou zaostalost. Takže tak.

[Sid]

ako sa prejavuje ta technologicka zaostalost? myslim tak ze ked v tom programujete tak v ktorych oblastiach je problem

dik

[Josef Kufner]

Nejde ani tak o toolkit, jako spíš o programy v něm napsané.

[Spike]

Já třeba pořád neviděl editor titulků nebo Jabber klienta pro KDE (nebo alespoň Qt), které by byly srovnatelné s tím, co je dostupné pro GTK+/Gnome. Na druhou stranu jsem nenašel podobně použitelnou alternativu k Amaroku, resp. foobar2000.

Takže pro mě osobně je to prašť jako uhoď - nakonec mi z toho vyjde, že z uživatelského hlediska nejlepší výběr mám na Windows.

[Poborskiii]

Co se týká editorů titulků, tak se konečně jeden pro KDE objevil: Subtitle Composer. To když tedy nepočítám již starší editor KSubtile, který ovšem po třech letech nečinnosti náhle vydal novou bugfix verzi 1.3.

[m1c4a1]

Dobře se v něm programuje? No já nevím, konstrukce jako gtk_button_new_with_label() ukazují, že čistý C není pro tvorbu GUI dvakrát výhodný, kód je pak komplikovanej a složitej.

[disorder]

nelubi sa objektovy pristup?

button = Gtk::Button.new("Hello World")
button.signal_connect("clicked") {
  puts "Hello World"
}

[Vinicius]

mm

[Martin Böhm]

Tak to pozor. Třeba já GNOME (i KDE) používám, a přesto si myslím, že to pořád není ta blesková rychlost, kterou by od toho člověk čekal. Jestli nějaké odvětví softwaru má šanci zabránit tomu všudypřítomnému "kynutí kódu" (Wirth's Law), je to svodobný software. Ale zatím se mu nedaří.

[Ondrej 'SanTiago' Zajicek]

Jestli nějaké odvětví softwaru má šanci zabránit tomu všudypřítomnému "kynutí kódu" (Wirth's Law), je to svodobný software. Ale zatím se mu nedaří.

Ale dari. Jenom si uzivatele casto sami vybiraji z bohate nabidky ten nakynuly software oproti stridmym alternativam.

[R]

Najviac sa stazuju ti, ktori nieco take musia pouzivat - napr. GIMP. Keby boli vsetky aplikacie, ktore potrebujem, pod Qt, tak by som sa na GTK+ nestazoval.

[Ctirad Feřtr]

Je ovšem třeba říct, že na GTK si nejvíc stěžují ti, co nejvíc nenávidí GNOME a GTK aplikace by stejně nepoužívali.

Podle sebe soudím tebe, co?

[petris]

Ja dokonce v GTK programuju(kvuli licenci) a tez na nej nadavam. Hlavne kvuli tomu, ze jsem si musel napsat vlastni souborovej dialog, protoze ten defaultni uzivatele s*al. To ze je ve srovnani s QT pomalejsi, je videt treba kdyz se zobrazuji roletky s hodne polozkama nebo kdyz si ve WM nastavite, at pri zmene velikosti oken ho okamzite prekresluje.

[JKK]

proti tomuhle bych se ohradil. GTK+ aplikace není totéž co GNOME. Hodně KDE-čkařů používá nezanedbatelné procento GTK+ aplikací. To přece s GNOME vůbec nesouvisí! Mě sice také vadí ta rychlost ... například file-save dialog, pominu-li to, že se mi nelibí ani z jiných úhlů pohledu....

[Creckx]

Podle tohohle tvýho popisu to vypadá, že GTK doslova stojí :) Já tu používám GTK i QT aplikace denně (ff,sonata,gajim,krusader,k3b) a ani u jedno nepozoruju to co tu popisuješ. Možná když má někdo nějakou šunku HW tak se to tam dá poznat, ale na mym athlonu X2 nebo Core solo to prostě poznat neni (Ani na Sempronu do Socket A, kterýho jsem ještě do nedávna měl).

[brk]

Kdy a kde se ta "pomalost" projevuje? Pomalé ve srovnání s čím?

Uznávám, že GTK+ s xychtíky typu Brushed má na línějším železe problém s překreslováním, ale že bych zrovna toto viděl nějak tragicky? Prostě tenhle vzhled ignoruji a nemám sebemenší problém.

[KS]

Přesně tak, žádná tragédie. Mám hodně starý a pomalý počítač, přesto k plné spokojenosti používám to hnusné a pomalé GNOME s hnusným a pomalým GTK+ a ještě hnusnějším a pomalejším Firefoxem a uplně nejhnusnější a nejpomalejší GTK# s Monodevelop. Nevím, odkud se bere tahle nenávist vůči těmto skvělým programům, které daly lidem spousty práce. Doporučil bych na to posezení u pchychiatra.

[David Jaša]

OT: mohl by sis poupravit nick. Pleteš se mi s J.M. výše.

[R]

A ten "hodne stary a pomaly pocitac" je Athlon XP 3000+, 1GB RAM alebo nieco podobne, ze?

[KS]

Celeron M, paměť je 1 GiB, ale na ni zas tolik nezáleží.

[..... Izak .....]

No jasne , jaj mam Athlon XP +1800 756MB RAM a nemam problem, pouzivam IceWM a jak GTK tak QT/KDE aplikace A PC je pres 5 let stare ... neb jsem investoval do foto studio vybaveni a staci .... ted kdyz prisela do Gimpu zaplata, tak u velkych ploch pozoruji brutalni narocnost, takze za cca 10.000kc provedu upgrade na 4 jadrovou X2 revize B3 2GB Ram a 2x500GB HDD (jeden dostanu, takze HDD koupim jen jeden), S-PVA 22" monitor uz mam.

Krucnal, AthlonXP uz je po bazarech za 2-3 tisice, kdo dela na necem horsim nez PIII ci AthlonXP nemam moc kafrat a pouzivat stare aplikace z te doby, pokud mu to staci, pokud ne tak at investuje, prace programatoru je draha a nemyslim si, ze by rychlost v Linuxu byla nejaky problem, to widnows vista maji mnohem vetsi naroky nez FC8 ci jakkoliv jina moderni Linux distribuce .... a to nehovorim o tom, ze i ta jde optimalizovat odlehcenym WM s mensimi pam. naroky.

[Jiří (BoodOk) Kadeřávek]

Počítač nemusí být jen ta navzhledná bedna, co Vám stojí pod stolem a žere minimálně jako obstarožní 100W žárovka (tak se kdysi říkalo svítícím teplometům). Tak jako výrobci procesorů pomalu začínají chápat, že budoucnost je v energeticky úsporných procesorech, tak obdobně by to měli začít chápat i výrobci SW. Mě, a ani Vám předpokládám, není jedno, kolik Vás provoz počítače stojí, kolik počítač váží a zda supluje funkci topení.

[xsubway]

suck less

Dedicated to software which sucks less…

The upper boundary on the size of the software we accept is 10,000 source lines of code (SLOC).

[cezz]

Pravda.. ja sice nemam nejaky extra stary pocitac, ale proste celkovo jak gtk aplikacie, tak gnome sa mi pouzivaju uplne bez problemov s nejakou pomalostou..

[vlastikroot]

Kdybys pouzival celeron 366 s 64MB RAM vedel bys co to znamena pomaly pocitac ;) Tam je to gnome opravdu pomaly ale jenom v nekterych widgetech . Urcite by se s tim dalo neco delat . Zlatej flux :D

[Andrej Herceg]

Pri 64MB pamäte sa nedá normálne používať žiadne grafické prostredie. ;) (kedysi som to skúšal, ale potom som musel pridať viac pamäte)

[R]

Od 128MB sa da celkom uspesne pouzivat KDE. Na rozdiel od GNOME.

[Nikola Ciprich]

to by me zajimalo ktery uchyl by to tak chtel pouzivat, kdyz pameti o takovych velikostech uz vam dneska klidne leckdo da zadarmo...

[J. M.]

Například moje matka má starší notebook se 128 MB RAM (a z toho si ještě kus sdílené paměti bere grafická karta) a KDE na tom léta v pohodě používá. Tak proč ne...

[washeck]

Mně na starém notebooku se 128MB RAM funguje xfce s GTK aplikacema docela slušně, tak proč kupovat nový?

[KS]

Celou střední jsem jel na Pentium 266 MHz, a pro GNOME to nebylo, ale tohle už jsou historicke stroje, každy nový mobil už má větší výkon.

[brk]

Někdy do listopadu 2006 jsem používal PII 366 MHz/192 MB s Xubuntu, takže XFCE, GTK+ a připadalo mi to OK. Samozřejmě jen do doby, něž jsem spustil Firefox, který co se RAMky týče "plnil na 110%", ale to už je o něčem jiném.

[R]

Tiez som pouzival XFCE, lebo som si myslel, ze je "light", ako sa to vsade pise. Ale potom som zistil, ze KDE je rychlejsie a navyse ma podstatne viac funkcii...

[J. M.]

Kdy a kde se ta "pomalost" projevuje? Pomalé ve srovnání s čím?

Uznávám, že GTK+ s xychtíky typu Brushed má na línějším železe problém s překreslováním, ale že bych zrovna toto viděl nějak tragicky? Prostě tenhle vzhled ignoruji a nemám sebemenší problém.

GTK+ je velmi pomalé i s tím nejrychlejším motivem vzhledu. Nicméně moderní vzhledy jej ještě velmi zpomalují.

Pomalé ve v porovnání s téměř čímkoli, kromě nativního GUI Windows (na které se nechytá téměř nic) typicky např. v porovnání s Qt (zejména verze 3.x).

Jeden názorný příklad za všechny (zachycený digitálním foťákem, programy zachytávající dění na obrazovce neumí zahycovat skutečné dění na obrazovce): na 2.4GHZ CPU trvá GTK+ vykreslení 128 spinuttonů do dialogového okna asi takto dlouho:

gtk-priklad.mp4

A z této šílené pomalosti se odvíjí všechno, netřeba to dál rozvádět.

[J. M.]

(Omlouvám se za ty překlepy a nedoklepy...)

[Pavel Vymetálek]

Myslíte, že je to dobře napsané GUI? Jsem toho názoru, že na editaci 128 čísel by se našlo mnohem lepší řešení...

GUI je věda a když vím, že ten který widget je pomalý, tak se mu v tomhle množství vyhnu...

[J. M.]

Mně je v tomto kontextu úplně jedno, jestli je chytré neobejít pomalost GTK+ nějakou lstí, nebavím se o tom dialogu. Je to prostě názorná ilustrace toho, že GTK+ je děsně pomalé. Sice je to zdánlivě extrémní případ, ale v každém běžném dialogu je takových prvků 10-20 a prostě to je pouhým okem vidět, jak se tam (např. při přepnutí záložky) postupně vykreslují. Což je naprostá rarita, žádný jiný GUI toolkit, který jsem kdy viděl, není takto superpomalý, že můžu v pohodě udělat screenshot toho, jak se mi i do běžného dialogu nebo záložky postupně vykreslují prvky jeden za druhým. GTK+ je prostě po technické stránce katastrofa.

[Jan Martinek]

Je dobře, že jsi našel chybu. Bez ohledu na to, že ji lze obejít řadou způsobů, je potřeba ji nahlásit a snad ji někdo opraví. To vykreslování je v tomto případě opravdu nesmyslně pomalé (s jinými widgety je to normálně rychlé), však si to může každý vyzkoušet na tomto:

#!/usr/bin/python
# -*- coding:utf-8 -*-

import gtk
N  = 20
a = [N*[0] for i in range(N)]

def value_changed(button, a, i, j):
    a[i][j] = button.get_value_as_int()

vb = gtk.VBox()
for i in range(N):
    hb = gtk.HBox()
    for j in range(N):
        adj = gtk.Adjustment(0.0, 0.0, 9999.0, 1.0, 10.0, 0.0)
        sb = gtk.SpinButton(adj, 0, 0)
        sb.set_numeric(True)
        sb.set_snap_to_ticks(True)
        sb.connect('value-changed', value_changed, a, i, j)
        hb.add(sb)
    vb.add(hb)
w = gtk.Window()
w.add(vb)
w.show_all()
w.connect('destroy', gtk.main_quit)
gtk.main()
print a

Vím ještě o dalších cca pěti případech, kde je gtk pomalé kvůli chybě (editace dlouhého řádku, několik dalších podivných situacích v TreeView a ve FileChooseru. Ale rozhodně bych kvůli tomu nezobecňoval, že "gtk je pomalé".

Nemohl byste někdo tento prográmek napsat i v Qt? Třeba by to urychlilo opravení chyby.

[Jan Martinek]

Píšeš, že při přepnutí záložky je vidět překreslování widgetů a ostatně i na tvém videu je to trošku vidět. Tohle podle mě NENÍ normální chování Gtk a máš tam možná něco shnilého. Jestliže si pustím v avidemuxu stejný konfigurační dialog jako ty a podržím Ctrl+PageDown s rychlostí klávenice 30 znaků za sekundu, tak se to úplně v pohodě stíhá vykreslovat. I tehdy, když frekvenci procesoru srazím na 1GHz.

[-=Majkl=-]

Tak pomale, ze vidim, jak se vykresluji jednotlive widgety, je to i u me. A nebude to "necim shnilym v systemu", ale spis shnilym GTK, protoze mi to dela jak v soucasnem Ubuntu, tak pred rokem, kdy jsem jeste pouzival Gentoo. BTW pouzivam Gnome a z 98% programy psane v GTK.

[Jan Martinek]

Možná je to subjektivní, tak bychom se měli bavit v konkrétních číslech. Program gtkperf, verze 0.40, okno zhruba doprostřed, defaultní nastavení (100 průběhů), všechny testy zapnuty. Za 10 sekund je hotovo (GeForce 6200, Sempron64 1.8GHz). Jesliže srazím frekvenci na 1GHz, trvá to 14 sekund. Na jiném počítači (tatáž grafika, Athlon XP 2500+) to trvá 11 sekund.

[San]

Jak to tak tady sleduji, tak tohle bude spíš o hw, distribuci a případném svinstvu v ní. Používám gnome resp. nyní xfce a gtk+ aplikace už nějaký ten pátek a to na různých strojích s různě silným hw (od Pentium II po Turion X2) a nikdy jsem neměl problém s pomalostí nebo vykreslování a to ani v graficky poněkud náročnějších aplikací jako je gimp. Tím ale nechci tvrdit, že to není možné, to ani náhodou, nicméně bych chybu zkusil hledat i jinde než v "zhnilém a pomalém" gnome.

[R]

Ktora je ta zazracna distribucia, kde je GTK rychle?

[San]

Není to žádná zázračná distribuce. Dříve to bylo ubuntu nyní zenwalk 5.

[J. M.]

Mně to dělá na všech počítačích, na kterých jsem GTK+ provozoval, na všech operačních systémech (včetně Windows). To je prostě vlastnost GTK+.

[J. M.]

Snad bych ještě dodal, že takhle brutálně se to celé zpomalilo po příchodu Caira v GTK+ 2.8, což byla známá a bolestná výkonnostní rána pro GTK+.

[disorder]

to sa mi zda divne, cairo je starsie

ale nie o tom som chcel, debian etch (2.8 tam je) pouzivam uz hodne dlho (na Athlon TB, C2D), nainstaloval som ho aj na 200MHz AMD K6 s 92MB RAM a XFCE je tam celkom v pohode (samozrejme pouzivat by som to dlhodobo nechcel, ale to nie je kvoli rychlosti Gtk+)

[J. M.]

Cairo je starší, ale je to samostatná knihovna, do GTK+ bylo zaintegrováno až ve verzi 2.8.

A samozřejmě to, co je celkem v pohodě, je relativní. V nějakých jednoduchých GTK+ aplikacích si běžný uživatel takových věcí moc nevšímá, navíc si zvykne... Čili samozřejmě použitelné to je, to snad nikdo netvrdí že ne. Ale doplácejí na to programy, které přešly z GTK+ 1.x na na 2.x. Ta režie, je strašná, ten výkon, který je vyplýtváván jenom na vykreslování GUI (což je u solidních toolkitů něco, co má mít prakticky nulovou, zanedbatelnou režii). Třeba v takovém Ardouru, vícestopém audio editoru, který taky přešel z GTK+ 1.x na 2.x, žere mnohonásobně více výkonu procesoru jenom zobrazení času, tedy textový popisek v GTK+  (!), než složité audio efekty, filtry na audio stopy v reálném čase. Jestli tohle není něco neskutečně absurdního, tak už nevím co.

[disorder]

no jasne, real time spracovanie audia rychlejsie nez vykreslenie jedneho widgetu, co nepovies :D

[J. M.]

Vzhledem k tomu, že zobrazení toho textového popisku, časového údaje, žere 10-15 procent výkonu procesoru, a běžné realtime audio efekty pod 1 procento, pak bohužel ano, je to tak. To je právě ta absurdita, které je GTK+ kuriózně schopno. Uživatel svobodného softwaru prostě platí daň za neefektivitu GUI tím, že značná část výkonu procesoru je spláchnuta do záchodu jenom zpracováváním toho samotného GUI. To je ve světě Miscrosoft Windows (které tímto nijak nepropaguji, sám k nim mám odpor) něco naprosto nemyslitelného, tam má GUI prakticky nulovou režii.

[Deleted [8409]]

Některé programy i pod Windows mají velkou režii pro GUI. Například ICQ.Ale samozřejmě máte pravdu v tom, že GTK je katastrofa. Když jsem začal používat linux, bylo pro mě GTK vzorové právě proto, protože bylo napsané v čistém C a já jsem si myslel, že to bude super rychlé... ajaj

[Jan Martinek]

Dobrá, tady je podobně jedovatě zelený popisek s černým pozadím jako je v Ardouru s ještě krávovitějším fontem a stíhá 1000 událostí za sekundu. Ale jaký má smysl mu jich tolik posílat? Vypovídá to něco o gtk?

#!/usr/bin/python
# -*- coding:utf-8 -*-

import gtk, pango

l = gtk.Label()
l.modify_font(pango.FontDescription("100"))
l.modify_fg(gtk.STATE_NORMAL, gtk.gdk.color_parse('green'))
w = gtk.Window()
w.modify_bg(gtk.STATE_NORMAL, gtk.gdk.color_parse('black'))
w.add(l)
w.show_all()
for i in range(5000):
    l.set_text('%04d' %i)
    while gtk.events_pending(): gtk.main_iteration()

[J. M.]

Smysl to má v programech, které to využívají. Jako např. audio editory. A o GTK+ to vypovídá to, že používat jej na serióznější, náročnější multimediální aplikace, je zhovadilost, neznalost a blbost programátora, který to dělá, protože režie GTK+ je větší než režie složitých multimediálních výpočtů (v programech tohoto typu, na rozdíl od primitivních desktopových aplikací, není výkon procesoru nazbyt a když GUI sežere desetkrát víc výkonu procesoru než to vlastní multmediální jádro, pak je to jednoznačné selhání úsudku při výběru toolkitu).

[J. M.]

Mimochodem, u mě to do těch 5000 dojede asi za 17 sekund, čili to máme tak 290 za sekundu při stoprocentním vytížení procesoru. Jenomže samozřejmě v audio editoru nemůže jeden jediný textový nápisek žrát sto procent výkonu, to musí být nula nula nic, což by tady v tom příkladu znamenalo tak max. 2-10 změn za sekundu, což je strašně ubohé. Ten audio editor musí současně dělat strašnou spoustu dalších věcí (např. zpracovávat audio, kromě zobrazování velké spousty dalších GUI prvků měnících se v reálném čase), u programů v Microsoft Windows je prostě vytížení procesoru v takových případech pořád nula, je nemyslitelné, aby si přehrání jedné stopy a vykreslování průběhu přehrávání (jak v audio stopě, tak těmi časovými nápisy) vzalo byť jen více než jedno procento. Protože ty prvky v microsoftím GUI jsou rychlejší snad tisíckrát.

Zkrátka, GTK+ je technicky ubohé a nikdy se to nezmění, protože jeho autoři už šest let ukazují, že nejsou ochotni ani schopni s tím cokoli udělat.

[petr_p]

Má smysl srovnávat widget z Windows s widgetem z GTK, když ten druhý narozdíl od toho prvního umí vybrat vhodný font, nahradit chybějící glyphy z jiného fontu, udělat rozumnou typografii (např. doplnit arabský text těmi kudrlinkami) a celé to vykreslit přes OpenGL?

[Deleted [8409]]

To nejsou žádné argumenty. Nahradit glyph je jedna podmínka někde v renderování písma a vykreslení pomocí OpenGL by mělo na rychlosti spíš přidat.

Takže ... ?

[eee]

To pochoputelne jsou argumenty. GTK je na kvalitativne vyssi urovni. V te ukazce je napriklad pismo vyhlazene, to samo je take narozne na vykon. Pres to vsechno neni GTK o mnoho pomalejsi. Jestli ma nejaka GTK aplikace pomale GUI, pak je to spatnym navrhem toho GUI, nikoli spatnym toolkitem. Napriklad programatori GTK gui obvykle pouzivaji dynamicky layout, GUI ve win aplikacich je z pravidla staticke. Dynamicke GUI je pro layout manager velmi narocny, musi neustale prepocitavat rozmery a umisteni prvku. Na druhou stranu pak lze v systemovem dialogu zmenit font a vsechny aplikace si ho za behu prenastavi. Toto chovani je by dafault. Jestlize delam aplikaci, kde chci, aby GUI melo co nejmensi rezii, tak mu vsechno nastavim staticky napevno a bude to o necem jinem. Je to tedy ciste vec programatora aplikace, jak to GTK pouzije.

[Deleted [8409]]

Jenže vy nechápete ten problém. Přepočítat layout není žádná věda, problém Gtk+ nastává tehdy, když potřebujete ty prvky na základě toho layoutu přemístit. Tím způsobíte vykreslení všech najednou a to Gtk prostě nezvládá.

Já si osobně myslím, že pomalost vykreslování v Gtk není způsobena samotným vykreslovacím algoritmem, ale spíše architekturou Gtk, která se z hlediska rychlosti nepovedla.

[eee]

Architektura je podřízena funkčnosti. GTK je pomalejší, než "toolkit" windows implementovaný v kernelu, ale je mnohem funkčnější. A to zpomalení není kritické. Jestli má nějaká GTK aplikace pomal= GUI, tak je to špatným použitím toho GTK. Snad jedině s vájimkou souborového dialogu, který by mohl být na adresářích s tisíci soubory fungovat lépe, tady vykreslovat je postupně a ne najednou. Tam vzniká uživatelsky pozorovatelná prodleva, ale není to tragické a nejde kvůli tomu odsuzovat celý toolkit.

[Jan Martinek]

Především, dík za všechny tvé příspěvky.

Jo a co se týče toho souborového dialogu a jeho rychlosti, tak největší zdržení je při zjišťování ikonek. Ta funkce totiž otvírá některé soubory a zjišťuje jejich typ (klasická ukázka je adresář /usr/bin s 3000 soubory). Jeho první načtení trvá minutu (zdržuje hard disk). Druhé načtení asi 2 sekundy (tohle ukazuje na rychlost Gtk).

A dá se udělat ještě další věc. Vynechat ikonky úplně a použít TreeView s "fixed_height_mode". To se zrychlí přímo dramaticky. Pak lze seznam souborů zobrazit fullscreen s dalšími sloupci (ext,size,atime,mtime) a rychlost je po zakešování zhruba 8000 položek za sekundu i v „pomalém“ Pythonu.

Přijde mi, že jestliže je u nějakého programu pomalé GUI, málokdy je na vině samotné Gtk.

[Deleted [8409]]

Klidně věřte tomu, že je Gtk úžasně vyspělý, dobře napsaný a rychlý toolkit. Nechápu, proč si prostě i zastánci Gtk nepřiznají, jak na tom Gtk je. Podle mého názoru je jediný důvod, proč Gtk ještě žije to obrovské množství aplikací, které ho používají + licence umožňující komerční vývoj.

[Jirka]

Spíš to, že pro komerční vývoj je stále *zdarma*.

[freshmouse]

Nerozumím GTK, nerozumím ani jiné knihovně tohoto typu. Nicméně větu "Nechápu, proč si prostě i zastánci Gtk nepřiznají, jak na tom Gtk je." nemohu považovat za argument. "Prostě jsem nejlepší, tečka."

[Deleted [8409]]

Takových už bylo :)

[J. M.]

Klidně věřte tomu, že je Gtk úžasně vyspělý, dobře napsaný a rychlý toolkit. Nechápu, proč si prostě i zastánci Gtk nepřiznají, jak na tom Gtk je. Podle mého názoru je jediný důvod, proč Gtk ještě žije to obrovské množství aplikací, které ho používají + licence umožňující komerční vývoj.

Souhlasím. Hlavní důvod používání GTK+ a vůbec jeho dominance v linuxových (a BSD či jiných) systémech je jeho licence. Což vědí i třeba výrobci mobilních zařízení, kteří jej používají se skřípěním zůbů, protože sice stojí za houby, ale je free. Taky po vydání GTK+ 2.8, které přineslo tu úžasnou integraci Caira, museli chudáci roky zamrznout na zastaralé 2.6, protože s tím Cairem už to bylo tak neúnosně pomalé, že už to ani ta free licence nepřebila.

[Deleted [8409]]

než "toolkit" windows implementovaný v kernelu

Achjo ... I kdyby bylo GUI ve Windows implementované kdekoliv, tak v tomto to určitě není. Pod X Window System lze také napsat rychlé GUI s velice dobrou odezvou.

Snad jedině s vájimkou souborového dialogu, který by mohl být na adresářích s tisíci soubory fungovat lépe, tady vykreslovat je postupně a ne najednou

Proč vykreslovat 1000 souborů, když se vám jich do dialogu vleze tak 20 ? Chce to použít další vlákno a ikonky MIME typů načítat až později, ale mám pocit, že to bych chtěl po Gtk vývojářich asi hodně.

[J. M.]

Souborový dialog GTK+ za prvé neumí zobrazit ani prázdný adresář s nula soubory bez viditelné prodlevy (což je světová rarita hodná Guinessovy knihy rekordů), jednak to, že objemné adresáře zobrazí pomalu rozhodně ani zdaleka není tím, že je na rozdíl od jiných toolkitů nezobrazuje postupně. Kéž by to bylo tak jednoduché. Pravá příčina je prostě ta, že ten souborový dialog GTK+ je superpomalý. I ty toolkity, které soubory zobrazují postupně, to komplet zobrazení adresáře dokončí několikanásobně rychleji než to dokončí GTK+.

A to druhé už je úplná pitomost. Toolkit má funkce a widgety od toho, aby se používaly. Správné používání toolkitu není nepoužívat jej a obcházet jeho pomalost. GTK+ by se podle této zvrhlé teorie mělo používat jen na nejprimitivnější GUI a cokoli složitějšího by se mělo obcházet nějakým zmrzačením. Navíc GTK+ neumí být rychlé za žádných okolností, ani když z programu kvůli pomalosti GTK+ uděláte mrzáka, který průběh času zobrazuje (na rozdíl od konkurenčních programů používající efektivnější toolkit) jenom trhaně, layout má jen minimalisticky primitivní, polovinu věcí si vykresluje radši sám a některé widgety radši nepoužívá vůbec. Pomalost GTK+ prostě člověk pociťuje kdykoli, v tom, jak se cokoli (i jednoduchého) pomalu překresluje, v tom, jak velkou režii mají i primitivní věci jako třeba otevření menu, které je pomalé jak měřitelně, měřičem vytížení CPU, tak pouhým pohledem na to, jak se líně vykresluje (a neříkejte mi, že to je špatné použití GTK+, že chytrý programátor nemá ve svém programu používat menu a tudíž je GTK+ rychlé, protože přestože je jeho menu pomalé, tak tím, že se nepoužívá, je ve výsledku rychlé, to je fakt demagogie).

Trvám na tom, že GTK+ je po technické stránce šmejd.

[David Jaša]

A to druhé už je úplná pitomost. Toolkit má funkce a widgety od toho, aby se používaly. Správné používání toolkitu není nepoužívat jej a obcházet jeho pomalost.

Pokud cokoliv překresluješ víc než 120x za sekundu (nejvyšší mě známá vertikální frekvence monitoru), tak pouze plýtváš výkonem CPU v jakémkoliv toolkitu (a podle toho, co píšeš, je to právě případ Ardouru).

[Jan Martinek]

Mě vadí, že se nechám od lidí jako ty vyprovokovat k tomu, abych se zvedl ze židle a šel k windows XP. Nastavil jsem rychlost klávenice na 30 cps, pouštěl různé programy a přepínal se mezi taby (Ctrl+PageDown/Up) případně zobrazil menu a podržel šipku doleva. U toho jsem sledoval zatížení CPU. Nejmíň jsem naměřil 30% (u ovládacích panelů, notepadu a ještě čehosi) a nejvíc asi u outlooku (nebo to byl explorer?) 70%. U Gtk (na linuxu) ty programy víc znám, takže jsem jich zkoušel daleko víc. Zátěž CPU byla 40-80%. Galeon (menu) cca 90%, asi mám hodně bookmarků. Snažil jsem aspoň trochu srovnávat to, co srovnávat šlo. Na linuxu byl trochu pomalejší procesor.

Gtk je pomalejší, má svých problémů dost, vím o nich a dost mě štvou. Ale dokud si nespravíš svou zkriplenou konfiguraci Xek, driverů, window manageru, gtk, nebo bůhvíčeho, dokud se u gtkperfu nedostaneš pod 15 sekund, dokud ti všechno pojede třikrát pomaleji, dokud se ti bude menu líně vykreslovat či pomalu přepínat záložky, tak se prosím tě k rychlosti Gtk nevyjadřuj.

[J. M.]

Zkriplenou konfiguiraci Xek v operačním systému Microsoft Windows zcela určitě nemám. Jak jsem již psal, GTK+ je pomalé na všech počítačích, na kterých jsem jej kdy viděl, na všech operačních systémech, na ktrerých jsem jej kdy viděl, a to i v prostředích bez X Window Systemu. Linux, BSD i Windows používám hodně dlouho a těch pozorování jsem za tu spoustu let provedl dostatek tisíc (pochybuji, že je na světě mnoho lidí, kteří by to sledovali a srovnávali tak pozorně a dlouhodobě jako já, ano i včetně mnoha testů s gtkperf, mimo jiné) na to, abych bezpečně věděl, že GTK+ patří ohledně GUI k tomu nejpomalejšímu. K tomu se rozhodně vyjadřovat vždycky budu.

[J. M.]

Mimochodem, k tomu „na všech počítačích a operačních systémech, na kterých jsem jej viděl“ bych přidal i „na všech videích, na kterých jsem jej viděl”, což dokazuje, že cbyba není na mých (a nejen mých, ale i všech ostatních, které mi přišly pod ruku) strojích. Všechna ta ilustrační videa, ať již jako předváděčky linuxových distribucí či záznamy z přednášek, to je jedna velká ostuda pro GTK+, je to na nich vidět stejně jako to vidím já na vlastní oči. Ještě nikdy v životě jsem neviděl něco, na čem by GTK+ běhalo skvěle.

[Jan Martinek]

17 sekund? Takže u tebe je gtk asi 3.5x pomalejší než na starém notebooku, na kterém jsem to zkoušel. Je to poznat i na tom videu, které jsi poslal.

[eee]

Tak to prr, 10 zmen cisla za sekundu neni ubohe, to uz clovek sotva stiha vnimat.

Vyse uvedena ukazka je benchmark GTK, nikoli smysluplne GUI. V praxi se takove GUI dela tak, ze se nezobrazuje kazde cislo, ale cislo v nejakem casovem intervalu. Zde je prepsany kod, v tomto smyslu. Neni to dokonale, spravne by gui melo bezet v jinem threadu nez vykonny kod aplikace, aby byl hw optimalne vyuzit, ale pro nazornost to staci.

#!/usr/bin/python
# -*- coding:utf-8 -*-

import gtk, pango, psyco, gobject
from   time import time

psyco.full()

class main(object):
    def __init__(self):
        self.cycle    = 0
        self.lastShow = time()

        self.l = gtk.Label()
        self.l.modify_font(pango.FontDescription("100"))
        self.l.modify_fg(gtk.STATE_NORMAL, gtk.gdk.color_parse('green'))

        w = gtk.Window()
        w.modify_bg(gtk.STATE_NORMAL, gtk.gdk.color_parse('black'))
        w.add(self.l)

        w.show_all()

        gobject.idle_add(self.update)

        gtk.main()

    def update(self):
        self.cycle += 1
        now         = time()

        if  now - self.lastShow < 0.1:
            return True
        self.lastShow = now

        if self.cycle > 500000:
            gtk.main_quit()
            return False

        self.l.set_text('%06d' % self.cycle)
        return True

main()

U me 500 000 cyklu probehne za necelych 8 sec. Pokud rychlost aktualizaci obrazovky zdesetinasobim (na nesmyslnych 100 za sekundu), pak tech 500 000 cyklu probehne za necelych 10 sec. Pritom drive uvedena ukazka s 5 000 cykly u me trvala 12 sec. Tedy je to cca 150 nasobne zrychleni aplikace (marketingove lepe zni zrychleni o 15 000 %). Berme to i jako nazornou ukazku mezi dobre a spatne udelanym gui. A proto znnovu opakuji, jestli ma nejaka aplikace pomale gui, je to predevsim chyba programatora toho gui a spatnym pouzitim toolkitu, nez toolkitem samotnym.

[Jirka]

Hmm, co to je 2.5d efekt? Non-standard UI mně docela děsí. A s nějakým zrychlením bych asi opravdu nepočítal, protože jestli chtějí každých 4-5 let změnit API/ABI, tak budou vždy přechodné stavy, kdy se budou používat obě verze knihoven a tím pádem rozdělení zdrojů mezi tyto knihovny. Navíc s vývojovým cyklem GNOME (kdy ke změnám dochází postupně) bych nepočítal s žádným hurá masivním přechodem na novou verzi jako to je teď s KDE. Ale uvidíme.

[disorder]

to si niekomu uveril, alebo si povodca toho vymyslu?

[Jirka]

Je slušnost alespoň napsat na co reaguješ!

[Honza "tux" Friesse]

100% offtopic, ale zkoušeli jste někdo Vala? Na mém postarším Slackware se mi to nedaří zkompilovat, ale podle popisu to vypadá extrémně zajímavě. Svobodný jazyk typu Java/C#, jehož kompiler převádí kód do C.