Dotaz: Rychlost GTK+

[Jindřich 'GoldenShit' Plešinger]

V jedne trapne debate "Gnome nebo KDE" se nekolik lidi vyjadrilo k tomu, ze GTK+ jsou pomale. Preferuji GTK a ani netusim proc, je to asi vec osobni sympatie, ale docela by me zajimal odborny a ne virou zaslepeny nazor, na rychlost GTK+. Take, zdali je nekdo vyvojarem, jeho slabiny a co se da cekat do budoucna. Za smysluplnou informaci moc dekuju. Preci jen programu, ktere pouzivaji GTK+ je docela dost a nejsou to nejake jednoduche male projekty.

www.xplesa.wz.cz

Odpovědi

[Jindřich 'GoldenShit' Plešinger]

Je prominte. Teprve ted jsem si vsimnul, ze reakce, ze GTK+ jsou pomale psal hlavne a snad pouze Nejakej Jakub na ktereho neni kontakt. Ale presto by odborna informace neskodila. Nic proti Jakubovi ale budu vdecny i za jeho odbornou informaci.

[Peter Konecny]

Ja aj ked nie som zaslepeny vierou, mam pocit, ze GTK apps su predsalen o nieco pomalsie ako qt... Je jedno ci je to odborny ci neodborny nazor... proste sa mi to tak zda a hotovo :)

[Factory]

GTK+ není pomalejší ani rychlejší než QT. Takhle nejde vůbec stavět otázku. Je třeba říct kde a kdy, za jakých podmínek, třeba pod windows bych řekl že GTK je pomalejší. Na Linuxu není podle mě žádný výrazný rozdíl. Že někomu náhodou běhá na Mindrake rychleji KDE nebo ve Fedoře GNOME, nevypovídá nic o GTK+ ani o QT. Co je důležitější, je jak se vám v tom kterém toolkitu programuje. Já dělám v gtkmm a PyGtk a musím říct že jsem spokojený. QT je od začítku v psaný C++ a kvůli tomu s sebou valí spoustu zbytečného balastu z doby, kdy ještě kompilery nebyly znormované. gtkmm naproti tomu je poměrně nový wrapper nad GTK+ C API a mnohem víc se podobá "modernímu" C++. Další věc je licence, QT patří Trolltechu a pro windows, jak víme, není zadarmo, takže pro mě je volba jasná.

[unchallenger]

Nemám zkušenosti s Qt na MS Windows. Gtk+ tam opravdu bývalo hodně pomalé, což už ale neplatí, možná i díky WIMP tématu. Testuji např. Gwyddion (viz signaturu) pod MS Windows na 233HMz notýskovi a GUI mi obecně pomalé nepřipadá, i když některé konkrétní widgety jsou trochu línější (ovšem některé z nich jsem vlastně napsal já, takže bych z pomalosti Gtk+ moc nevinil ;-)

[Factory]

To rád slyším, moje poslední zkušenosti s GTK na windows jsou z jedničkové řady.

[unchallenger]

Zkušenosti s Gtk+1 na Win32 vůbec neber vážně, tehdy bylo Gtk+ na Win32 dost experimentální záležitost, a všichni byli rádi, že to jede aspoň nějak.

[Luboš Doležel (Doli)]

Mám otázku, která se týká KOMERČNÍHO/neOpenSource použití QT a GTK:

1) Vím, že za použití QT ve Windows musím platit. Musím platit i za komerční použití QT pod Linuxem?

2) Mohu použít Gtk v neOpenSource programu?

[Michal Marek (twofish)]

1) Ano (GPL)

2) Ne (LGPL)

[VícNežNic]

LGPL přece použití v neOSS umožňuje, nebo se někde krutě mýlím?

[Whale]

Nemýlíte, viz níže.

[Michal Marek (twofish)]

Jsem blbec, nevšim jsem si, že se jednou ptá, jestli nesmí, a podruhé jestli smí :-/

[Whale]

1) Ne, ale nelze použít pro closed-source (GPL), nebo si lze koupit komerční licenci.
2) Ano (LGPL)

[jm]

No, tak se panove nejak dohodnete.

[VícNežNic]

Viděl bych to na pistole

[Michal Marek (twofish)]

Pokud komerční znamená closed-source, tak se dohodneme na "ano ano"

[Palo]

Gtk+ je ovela pomalsie (viditelne !) ako Qt, hlavne zlozitejsie widgety (napr. GtkTreeView, ako tu uz viaceri spomenuli). A ani sa nedivim, pozrite si napriklad ako sa pridavaju vlastnosti do GObject - katastrofa, identifikuju sa retazcami ! A pri kazdej prilezitosti sa robi marshalling, to tomu tiez nepridava na rychlosti. CORBA-cke object linking & embedding v Gtk+, t.j. Bonobo, sa ukazalo byt tak pomale, ze v niektorych projektoch vyhodili prislusny (uz existujuci) kod, pretoze bol nepouzitelny. Okrem toho, myslim, ze nove verzie Qt maju vsetky widgety zoptimalizovane, aby pouzivali OpenGL. A samozrejme, Qt pouziva Unicode, t.j. 2 bytes / char, co je na vypocty ovela jednoduchsie nez UTF-8 sekvencie v Gtk+, aj ked tym padom nie su podporovane niektore obskurne jazyky... Co sa tyka zbytocneho balastu, mate zrejme na mysli metacompiler pouzivany kvoli signalom (nic ine tam uz asi nie je). Fakt je, ze libsignal v gtkmm je z hladiska designu ovela krajsie a hlavne cisto C++ riesenie, na druhej strane sa na kazdy signal spotrebuje o 4 bytes viac pamate (a je mozne, ze je to aj trosku pomalsie, ale nie som si isty) a strasne pomaly sa to kompiluje (vyuzivaju sa vo velkom sablony a kompilatoru to robi znacne problemy). Co sa programovania tyka, Gtk+ je oproti Qt uplna katastrofa, hlavne kvoli chybajucej / odflaknutej dokumentacii (nie, ani gtkmm vam v tomto smere moc nepomoze) a kvoli tomu, ze Gtk+ je pisane v C. Povedal by som, ze napisat Gtk+ aplikaciu je radovo narocnejsie nez v Qt, so vsetkymi dosledkami (citatelnost kodu, doba vyvoja, ...) Situacia je natolko zufala, ze v Gtk+ komunite prebiehaju diskusie akyze jazyk vyssej urovne zacat nativne podporovat, zatial to vyzera na C#, vzhladom na zname aktivity Novell-u... (Mono) Binarny standard C++ uz existuje aspon pol roka, takze ak v TrollTech-u dotiahnu veci do konca, neviem, neviem, na co sa budu chlapci z Gtk+ v buducnosti vyhovarat... S cim ale musim absolutne suhlasit je otazka licencii. Pre mna osobne to je dovod, preco napriek vsetkym chybam programujem v Gtk+ a nie v Qt.

PS: Dva hlavne dovody, preco bolo pre Gtk+ zvolene C, boli rychlost a portabilita (problemy s C++ kompilatormi na Windows). Ironiou je, ze dnes je Qt v C++ rychlejsie nez Gtk+ v C a na rozdiel od neho skutocne bezi aj pod Windows

[unchallenger]

Tvrzení o identifikaci řetězci je blud. K vlastnostem existují obvykle dva způsoby přístupu: generické (g_object_set(), identifikace řetězcem) a specifické metody get_něco(), set_něco().

Tvrzení o marshallingu bylo samozřejmě nadhozeno v konferenci Gtk+ (a myslím ne jednou), ale nikdo ho nikdy nedokázal podpořit čísly. Dokážeš to ty?

Pokud jde o Qt a OpenGL, doporučuji méně myslet a více si zjišťovat fakta.

Pokud jde o signály, vystačil jsem si s obyčejnými GObject signály, takže mě metakompilátory a templaty netrápí.

Pokud jde o navážení se do C, tak děláš-li to z posice C++, mohu se leda smát. C je nízkoúrovňový jazyk, takže to, že v něm lidé (já také) dnes píší GUI aplikace, je patrně omyl. Ovšem C++ je C zatížené second-system efektem ;-) Není ani dost vysokoúrovňové, aby ses nemusel sám starat o alokaci a uvolňování paměťi a psalo se v něm bez hromady balastu (srv. Python), ale ani dost nízkoúrovňové jako C, abys v něm měl tu alokaci pevně v rukou, děláš-li systémové programování (nepoužíváš-li ho prostě jako C-kde-je-const-opravdu-const). Většinu špatných věcí o C můžeš říci i o C++, a k tomu spoustu nových.

Pokud o to, který další jazyk nativně podporovat, tak nechápu. Že se jeden binding (GTK#) prohlásí za oficiálně podporovaný? To by se mohlo stejně dobře udělat s pygtk i dalšími. Že se celé Gtk+ přepíše do C#? No, to asi ne. Takže Gtk+ zůstane implementováno v C, a o co tedy jde?

Borci z Trolltechu dotáhnou věci do konce, až bude Qt na všech platformách free. Do té doby si ho mohou dát zarámovat.

Pokud jde o portabilitu C++ a bugovost kompilátorů C++, tak je to dnes lepší než před lety, což znamená jen nic moc, už ne naprostá katastrofa. A pročpak si asi každý drhuhý v C++ implementuje svůj vlastní ekvivalent STL?

[Jakub]

Nejmarkantnější rozdíl je v rychlosti překreslování a změny velikosti.

Zkuste plynule měnit velikost okna u Qt a GTK+ 2.x (*NE* 1.x! to bylo rychlé) se zapnutým zobrazováním obsahu okna. Hlavně u složitějších dialogů a oken. Qt mění velikost plynule, téměř jako MS Windows GUI (s kvalitními ovladači grafické karty), s GTK+ 2.x uvidíte značné zpoždění a pomalé/trhané/skákavé překreslování.

Tohle je zdaleka nejznámější rychlostní problém GTK+ 2.x, o tom byly napsány tisíce příspěvků, tohle uznávají i příznivci a autoři GTK+ (kteří to ale omlouvají tím, že lidi stejně moc často nemění velikost oken, tak je to jedno). Tohle je všeoběcně známý nedostatek GTK+, přečtěte si např. diskuse na osnews.com (skoro v každém článku o GTK+) atd.

Další notoricky známý problém GTK+ 2.x je rychlost překreslování obecně. To je obzvlášť markantní v různých grafických aplikacích.

Snad se blýská na lepší časy - po velmi dlouhém ignorování problému a neustálých stížností vývojáři GTK+ konečně začali na těchto známých problémech pracovat a nová vývojová verze 2.5 (ze které bude stabilní 2.6) obsahuje konečně nějaké optimalizace pro změnu velikosti a rychlost překreslování (podpora update counter pro plynulejší změnu velikosti, snížení počtu nutných překreslení). Četl jsem, že to prý trochu pomáhá, ale stále to ještě není ono. Nezkoušel jsem.

Za značnou částí pomalosti GTK+ 2.x je prý Pango, které je zodpovědné za zobrazováné textu. To je i podle autorů GTK+ velmi neoptimalizované a mohlo by být mnohonásobně rychlejší, kdyby na tom zapracovali. Údajně to souvisí s jeho obecností, kdy stejným způsobem jako nějaké exotické jazyky zobrazuje i písma latinky, což by se dalo zoptimalizovat.

Zkuste používat CPU metr a zkoušet vytížení CPU v různých situacích. Máte-li nějaký dlouhý seznam položek, používajích TreeView v GTK+ a rolujete nahoru/dolů, GTK+ 2.x už skoro nestíhá. Stejně tak triviální věci jako zobrazení menu, přepínání záložek (kde u GTK+ 2.x často vidím pomalé postupné překreslování obsahu) a řada dalších věcí jako posouvání částí okna atd. žere v GTK+ víc výkonu CPU.

Pak je řada věcí, ve kterých jsou GTK+ a Qt zhruba stejně rychlé. Ale ty výše zmíněné rychlostní problémy GTK+ jsou opravdu notoricky známé, to se neustále omílá v diskusích už od vzniku GTK+ 2.x, na to si permanentně stěžují spousty lidí.

[nobody]

Suhlas

[Swarz]

Aha tak proto sa ten Azureus-gtk (Bittorrent client) tak pomaly prekresluje....stim rolovanim atd. suhlasim s Jakubem.

[zoliq]

Netvrdim, ze GTK samo o sebe rychlejsie co sa tyka rychlosti vykreslovania grafiky, nakoniec QT je vytvor firmy, ktora sa tym zivi. Ale prekreslovanie grafiky je vo vacsine pripadov fakt, ktory az tak nezavazi na rychlosti celkoveho desktopu. Na druhej strane KDE ma tolko grafickych efektov, ze vo vykreslovani znacne spomaluje (tienovanie, presvitanie atd.).
Okrem faktu, ze QT je neopen source projekt je dolezitym faktom (co sa rychlosti tyka) to, ze je cely (a vlastne cele KDE) napisany v C++. C++ sa snazi kontrolovat kod omnoho preciznejsie ako klasicke cecko. Dosledkom toho je mnozstvo vlozeneho kodu, ktory je naviac a ktory sa musi vykonat ci chceme alebo nie. Napriklad 3 riadkovy zdrojak (hello) mal po prelinkovani v g++ o 1KB vacsi kod ako v gcc. A to je 3 riadkovy zdrojak! ... kolko riadkov ma samotne QT? A toto sa netyka len vykreslovania grafiky - celkovo su spomalene aj aplikacie postavenie na knizniciach pisanych v C++.

[Factory]

QT je open source. Na Linuxu dokonce GPL! Na Win bohužel ne, ale stále je alespoň zčásti OS.

Jestli je QT skutečné C++ je otázka, nicméně použití jazyka vyšší úrovně téměř vždy vyvažuje množství balastu s tím spojeného. Na rozumně novém počítači už je to zkrátka jedno.

[VícNežNic]

Nj, to je faktor, který činí Qt nevhodné pro velkou část open source vývoje. Nevadí, že nelze vyvíjet uzavřený software. Ovšem nevím který FOSS projekt by se nechal Qt takto omezovat v přenositelnosti. (myslím, že Mac OS verze je taky placená, jestli se to týká té verze Qt pro přenosná zařízení teď nevím)

To fakt radši sice možná ne tak dokonalý ale zato skutečně otevřený a i na windows použitelný GTK+

[Factory]

A vám jde o co? Co tím získáte, když budete psát pamflety na GTK? Místo psaní tak dlouhého zbytečného článku jste mohl pracovat na zrychlení Panga, a pokud neumíte programovat, mohl jste například lokalizovat svou oblíbenou QT aplikaci, nebo třeba napsat chybějící manuál.

V Linuxu si můžete zvolit co budete používat. Možná vás to překvapí, ale mnoho lidí volí GTK, ať už z jakéhokoliv důvodu. Třeba proto že jsou úplně blbí. Nebo co se snažíte dokázat? Nikdo vás tu nepřesvědčuje, že pro vaše blaho bude nejlepší GTK. Proč vy tak nadšeně evangelizujete QT? Vždyť jde o h..o ne?

[Jakub]

Mně na rozdíl od vás jde jen o to, že jsem klidně, věcně a bez emocí odpověděl na otázku Plesingera Jindricha (který mě k tomu výslovně vyzval) v čem je GTK+ pomalé. Žádné osobní preference ani evangelizaci jsem tím neprojevil. Na rozdíl od vás se domnívám, že když je něco v něčem špatné, není trestné se o tom zmínit jenom proto, že vás to jako příznivce GTK+ štve. Já GTK+ taky fandím, ale to v téhle diskusi nemá co dělat - zametání problémů pod koberec je to, co neuznávám a kritizuju. GTK+ se nezlepší tím, že jeho problémy budeme ignorovat a místo toho se věnovat překladům Qt programů.

[Factory]

To je nedorozumění. Aby bylo jasno - nejsem příznivcem, zastáncem, ani modloslužebníkem žádného grafického toolkitu:) Na to jsem příliš starý a mám taky jiné starosti k řešení:) Všimněte si, že moje reakce byla též věcná a klidná (snad, tedy možná jsem mohl volit jemnější tón, omlouvám se, píšu jak mi zobák narost), tak prosím neštěkejte. Co chci říct, znovu a lépe - kecama nic nezpravíme. Je lepší něco praktického udělat.

[Jakub]

S poslední větou souhlasím, s předposlední nikoli. To byste se divil, co se kecama změní. Kdyby GTK+ 2.x nebylo tak masivně a permanentně kritizováno za svou pomalost, nevím, jestli by se tím jeho autoři zabývali aspoň tak jako teď (rychlostní optimalizace v posledních několika měsících). Navíc, já jsem svůj dlouhý příspěvek neposlal svévolně, ale pouze na výslovnou výzvu tazatele, jako odpověď na jeho otázku. Sám od sebe bych sem nic takového necpal, takový blázen zas nejsem.

[Jindřich 'GoldenShit' Plešinger]

Diky za info. Byl bych nerad, jestli jsem nekoho urazil, ale nakonec musim podekovat vsem co neco zajimaveho dodali. Jakube dik, asi jsem psal o tobe trochu spatne, ale bohuzel musi s tebou souhlasit. Uz toho nechme.

www.xplesa.wz.cz

[unchallenger]

K dlouhým TreeView bych poznamenal, že TreeView má bohužel výkonostní problémy samo o sobě, v konferenci Gtk+ se pořád obejvují lidé, co si vyrobí z databáze TreeView s 40k položkami, a pak se hrozně diví...

Zobrazení menu je IMHO pomalé subjektivně, ono se tak pomalu nevykresluje, ale je tam timeout. Lze ho změnit v gtkrc (gtk-menu-bar-popup-delay a spol.)

Přepínání záložek mi přijde okamžité (asi dělám něco špatně ;-) ani jsem si moc nevšiml nějakých stížností.

Renderování textu Pangem je asi 100x pomalejší než prsknout někam text přímo přes Xlib, proto také doufám, že se to zlepší, OTOH Pango bych raději, aby nejprve fungovalo správně a obecně (např. až verze 1.6 přidává podporu pro lineární transformace při renderování, jako třeba otočení), a optimalizovalo se až poté.