abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
dnes 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
dnes 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 0
včera 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 24
včera 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 784 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Rychlost GTK+

14.12.2004 14:52 Jindřich 'GoldenShit' Plešinger | skóre: 16 | blog: Nevěřící | Dolní Bousov
Rychlost GTK+
Přečteno: 231×
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
LINUKS = Lidová Nacionálně Ultralevicová Komunistická Strana

Odpovědi

14.12.2004 15:06 Jindřich 'GoldenShit' Plešinger | skóre: 16 | blog: Nevěřící | Dolní Bousov
Rozbalit Rozbalit vše Re: Rychlost GTK+
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.
LINUKS = Lidová Nacionálně Ultralevicová Komunistická Strana
14.12.2004 15:11 Peter Konecny | skóre: 4 | Bratislava
Rozbalit Rozbalit vše Re: Rychlost GTK+
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 :)
14.12.2004 16:49 Factory
Rozbalit Rozbalit vše Re: Rychlost GTK+
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á.
14.12.2004 17:11 unchallenger | skóre: 69 | blog: unchallenger
Rozbalit Rozbalit vše Re: Rychlost GTK+
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 ;-)
14.12.2004 17:14 Factory
Rozbalit Rozbalit vše Re: Rychlost GTK+
To rád slyším, moje poslední zkušenosti s GTK na windows jsou z jedničkové řady.
14.12.2004 17:23 unchallenger | skóre: 69 | blog: unchallenger
Rozbalit Rozbalit vše Re: Rychlost GTK+
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) avatar 14.12.2004 20:12 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Rychlost GTK+
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?
14.12.2004 20:15 Michal Marek (twofish) | skóre: 55 | blog: { display: blog; } | Praha
Rozbalit Rozbalit vše Re: Rychlost GTK+
1) Ano (GPL)

2) Ne (LGPL)
14.12.2004 20:40 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
Rozbalit Rozbalit vše Re: Rychlost GTK+
LGPL přece použití v neOSS umožňuje, nebo se někde krutě mýlím?
Copak toho není dost?
14.12.2004 20:48 Whale
Rozbalit Rozbalit vše Re: Rychlost GTK+
Nemýlíte, viz níže.
14.12.2004 21:02 Michal Marek (twofish) | skóre: 55 | blog: { display: blog; } | Praha
Rozbalit Rozbalit vše Re: Rychlost GTK+
Jsem blbec, nevšim jsem si, že se jednou ptá, jestli nesmí, a podruhé jestli smí :-/
14.12.2004 20:36 Whale
Rozbalit Rozbalit vše Re: Rychlost GTK+
1) Ne, ale nelze použít pro closed-source (GPL), nebo si lze koupit komerční licenci.
2) Ano (LGPL)
14.12.2004 20:48 jm
Rozbalit Rozbalit vše Re: Rychlost GTK+
No, tak se panove nejak dohodnete. :-D
14.12.2004 21:00 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
Rozbalit Rozbalit vše Re: Rychlost GTK+
Viděl bych to na pistole :-)
Copak toho není dost?
14.12.2004 21:03 Michal Marek (twofish) | skóre: 55 | blog: { display: blog; } | Praha
Rozbalit Rozbalit vše Re: Rychlost GTK+
Pokud komerční znamená closed-source, tak se dohodneme na "ano ano" :-)
14.12.2004 22:39 Palo
Rozbalit Rozbalit vše Re: Rychlost GTK+
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 :-)
15.12.2004 00:14 unchallenger | skóre: 69 | blog: unchallenger
Rozbalit Rozbalit vše Re: Rychlost GTK+
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?
14.12.2004 17:38 Jakub
Rozbalit Rozbalit vše Re: Rychlost GTK+
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í.
14.12.2004 19:06 nobody
Rozbalit Rozbalit vše Re: Rychlost GTK+
Suhlas
14.12.2004 19:51 Swarz | skóre: 12 | blog: trapeni_informatika
Rozbalit Rozbalit vše Re: Rychlost GTK+
Aha tak proto sa ten Azureus-gtk (Bittorrent client) tak pomaly prekresluje....stim rolovanim atd. suhlasim s Jakubem.
14.12.2004 19:49 zoliq | skóre: 8 | Puchov
Rozbalit Rozbalit vše Re: Rychlost GTK+
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++.
14.12.2004 20:27 Factory
Rozbalit Rozbalit vše Re: Rychlost GTK+
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.
14.12.2004 20:38 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
Rozbalit Rozbalit vše Re: Rychlost GTK+
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+
Copak toho není dost?
14.12.2004 20:16 Factory
Rozbalit Rozbalit vše Re: Rychlost GTK+
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?
14.12.2004 20:29 Jakub
Rozbalit Rozbalit vše Re: Rychlost GTK+
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ů.
14.12.2004 20:46 Factory
Rozbalit Rozbalit vše Re: Rychlost GTK+
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.
14.12.2004 20:54 Jakub
Rozbalit Rozbalit vše Re: Rychlost GTK+
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.
14.12.2004 21:25 Jindřich 'GoldenShit' Plešinger | skóre: 16 | blog: Nevěřící | Dolní Bousov
Rozbalit Rozbalit vše Re: Rychlost GTK+
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
LINUKS = Lidová Nacionálně Ultralevicová Komunistická Strana
14.12.2004 21:14 unchallenger | skóre: 69 | blog: unchallenger
Rozbalit Rozbalit vše Re: Rychlost GTK+
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é.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.