Vyšlo GTK 2.8 (diskuse)

[Jakub]

Byl bych moc rád, kdyby se vývojáři GTK+ konečně, poprvé v historii, zaměřili na výkon. Celá léta tisíce uživatelů neustále masivně zaplavují veškeré diskuse o GTK+ neutuchající monotematickou smrští stížností na pomalost GTK+ 2.x, a vývojáři to celá léta ignorovali. A teď vydají novou verzi založenou na Cairu, které je neoptimalizované a ve výsledku to je i podle tvůrců GTK+ a jeho témat ještě pomalejší než předtím. To je opravdu zoufalé.

[unchallenger]

Celá léta tisíce uživatelů neustále masivně zaplavují veškeré diskuse o GTK+ neutuchající monotematickou smrští stížností na pomalost GTK+ 2.x...

No, a i kdyby ne, tak ty je v tom rád zastoupíš...

[Luboš Doležel (Doli)]

A já mu s tím pomůžu.

Proboha, i ten .NET pod Win32 se svým GDI+ vykresluje bitmapu do okna rychleji než GTK+ pod Linuxem.

Je GTK+ alespoň pod Win32 rychlejší?

[unchallenger]

Gtk+ aplikace může kreslit bitmapu od vykreslování bod po bodu gdk_draw_point() až po použití GtkGLExt. A čo vy si Kefalín predstavujete pod takým slovom vykresluje bitmapu? Která je to ta pomalá operace?

[Luboš Doležel (Doli)]

bool MyWin::on_area1_expose_event(GdkEventExpose *ev)
{
	Glib::RefPtr<Gdk::Window> window = area1->get_window();
	Glib::RefPtr<Gdk::GC> gc = Gdk::GC::create(window);
	Gdk::Rectangle area;
	
	area = Gdk::Rectangle(&ev->area);
	
	window->begin_paint_rect(area);
	
	window->draw_pixbuf(gc, pixbuf, area.get_x(), area.get_y(), area.get_x(), area.get_y(),
		area.get_width(), area.get_height(), Gdk::RGB_DITHER_NORMAL, 0, 0);
	window->end_paint();
	return true;
}

pixbuf je nějaký naloadovaný obrázek. Dělám něco špatně/neefektivně?

[unchallenger]

Pokudj jsme si to správně přeložil zpět do C, děláš tripple-buffering namísto obvyklého double-bufferingu (který dělá Gtk+ samo). Viz dokumentaci funkcí, které tam používáš. Na vytvoření nového grafického kontextu se doufám nemusí komunikovat s X serverem -- pokud ano, tak by to taky zdržovalo, jinak je jen zbytečné dělat to při každém expose eventu znovu.

[Luboš Doležel (Doli)]

Nevím v čem v tom kódu spočívá ten tripple-buffering...?

Rodič dostane zprávu, že area1 bylo exposed, tak exposed oblast vykreslí.

[unchallenger]

Tak si přece tu dokumentaci gdk_window_begin_paint_region() přečti.

[Luboš Doležel (Doli)]

Aha. Z ní mám pocit, že GTK+ žádný buffer samo nemá a že tímhle zajistím jen double-buffering.

[unchallenger]

When using GTK+, the widget system automatically places calls to gdk_window_begin_paint_region() and gdk_window_end_paint() around emissions of the expose_event signal. ...

Tak buď se to neodehrává v expose event handleru, nebo máš double-buffering vypnutý a děláš ho ručně (a pak je tedy jen double-), nebo fakt každý čteme jinou dokumentaci.

[Luboš Doležel (Doli)]

Aha, tak daleko jsem to nedočetl. Sorry

Takže musím uznat, že to tak pomalé není, ale samotné GUI prvky (tlačítka) apod. se mi pomalejší zdají - to už je ale hodně subjektivní.

[Jakub]

Je GTK+ alespoň pod Win32 rychlejší?

Není. Zkoušel jsem aplikaci s GTK+ 2.6 ve Windows XP, a oproti tomu je verze pro Xka ještě celkem svižná. Změna velikosti okna je totálně strašná (obsah vůbec nereaguje dokud nepřestanete měnit velikost), vykreslování jednotlivých oken je viditelně pomalé (windowsové GUI se na obrazovce objeví okamžitě a celé, v GTK+ často vidím jak se okno postupně na obrazovku vykreslí), stejně tak překreslování (např. když přes okno s GTK+ aplikací přejedete jiným oknem, to se nedá s nativním Windows GUI ani trochu srovnat), při přepínání záložek vidím jak se postupně vykreslují jednotlivé prvky v záložkách a vůbec to má všechny ty atributy pomalosti jako v Xkách - běžné věci jako otevření menu (při kliknutí pravým tlačítkem, otevření combo boxu atd.) nebo položky v TreeView atd. prostě žerou několikanásobně víc výkonu procesoru než nejen windowsové GUI, ale i třeba Qt. A to jak ve Windows, tak i Linuxu či BSD.

[Šafránek]

To je zvláštní, že já nic takového nepozoruji. A to ani v aplikaci napsané v interpretovaném Pythonu (2.4.1) s použitím GTK (2.6) na Pentiu MMX 233 MHz. Mohl bys mi uvést příklad takovéto pomalé aplikace?

[unchallenger]

Na čem to proboha provozuješ? Takhle se Gtk+2 pod MS Windows nechová ani na mém notebooku, což je Pentium II na 233 MHz. Je tam normálně použitelné, byť je pomalejší než nativní GUI. Obsahy oken se při změně rozměrů překreslují (což nesnáším, takže to vím docela jistě). Není náhodou chyba na tvém přijímači? Jediný symptom, který pozoruji, je nepřekreslování oken, když přes ně přejíždíš jiným oknem.

[Jakub]

Provozuji to na Pentiu 4 2.4 GHz. Ale nejen na něm. To není nic specifického pro tento počítač. A to, že s GTK+ je u řady běžných úkonů několikanásobně vyšší vytížení procesoru než u konkurence je snadno ověřitelný a změřitelný fakt.

[Šafránek]

To jako že něco netrvá 0.001 s ale 0.01? Možná, ale když to není pozorovatelné (je to potřeba měřit), tak to nestojí za řeč. To za lepší použitelnost GTK stojí. V praxi to není nijak omezující a to ani na historických strojích, s kterými se člověk setká jen vzácně. A Cairo přinese revoluci na desktop, z bitmapového se stane vektorový. To je významný krok vpřed, stejně jako tomu bylo při nahrazení bitmapových fontů vektorovýma.

[Jakub]

No, a i kdyby ne, tak ty je v tom rád zastoupíš...

To naštěstí nemusím, protože to takhle prostě je. Stačí si projít třeba jakoukoli diskusi o GTK+ nebo GNOME na osnews.com atd.

[ND]

Stačí si projít diskuse o GTK na ABCLinuxu. Aspoň se nepodepisuj vždy poctivě Jakub, aby to nebylo tak trapný :)

[Jakub]

Aha, příště budu předstírat víc falešných identit, aby to nebylo trapný. Fajn.

[ND]

Fajn, nebude se mi otvírat kudla v kapse, kdykoliv se seznámím s nějakým Jakubem

Ne nic ve zlém, nemyslím nějak agresivně, jen se mi moc chce napsat: jsi tak strašně, strašně, strašně mimo.

Omlouvám se, někdy neumím být diplomat, je mi to líto.

Mimochodem, dost mi připomínáš JXD.

[Jakub]

Já na rozdíl od tebe všechno co říkám podepírám argumenty - vysvětlením co říkám a proč to říkám, všechno co jsem napsal je založené na mé letité zkušenosti a důkladném pozorování.

Ty jsi byl schopen přijít jen s vágním "jsi tak strašně, strašně mimo" a "podváděj, abys nebyl trapnej", bez vysvětlení čehokoli. Pokud někomu řekneš že je totálně mimo a neřekneš proč, je to naprosto bezcenné a nemá to sebemenší váhu.

[s0]

Cairo je prima, akorát by opravdu mohli něco udělat s výkonem ;) Ve Scribusu jsme s tím dělali pár pokusů - pro programátora je jejich API hodně slušné, ale aplikace s tím v podstatě zamrzla...

[14:01:35] mrdocs: ishmal: did you know Franz 
ported Scribus to use cairo as a render ?
[14:02:21] Jizzbug: So I guess libart is dead, huh?
[14:02:41] Jizzbug: libart_lgpl is dead! Long live libart_lgpl!
[14:04:11] ishmal: really?  cool
[14:04:31] mrdocs: ishmal: took him half a day
[14:04:57] mrdocs: and we sent the patches to cworth to 
let him play
[14:05:13] mrdocs: the big holdback is performance
[14:05:34] mrdocs: display was almost 100% correct right 
out of the box
[14:06:45] mrdocs: and as cairo matures, it still will be 
possbile to graft it in later.. Franz liked the API and 
ease of using :)

anebo: mailing list

[Dominik Joe Pantůček]

Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension or OpenGL). (www.cairographics.org)

[petr_p]

Jenze proti libart je to porad hlemyzd. (Vecne diskuze rychlost versus mnozstvi funkci lze najit ve vyvojarskych diskuzi SVG podpory ve Firefoxu.)

[Luboš Doležel (Doli)]

Předpokládám, že XRender a nVidiácký RenderAccel spolu souvisí (?)

Pokud teď GTK+ nepoužívá XRender, tak by to vystvětlovalo, proč je u mě Qt výkonnější než GTK+.

[polov]

mozna budu vypadat blbe, ale mam problem s kompilaci. cairo a libpix... se zkompiluji v pohode, glib taky, atk taky, kamen urazu je pango. pango 1.9.X nejde zkompilovat s cairem 0.9.2 a to je zase minimum pro gtk+. Jde pango 1.9.X nejak zkompilovat spolu s cairem 0.9.2? Mam FC3.

[Radomír Fojtík]

Problémy s kompilací mají i někteří Gentooisté. Těm co se to nakonec povedlo, nakonec jen spílají.

[unchallenger]

Problémy se objevují i v konferenci Gtk+... Počkal bych alespoň na vydání stabilní verze Panga, tj. 1.10. Měla vyjít s Gtk+ 2.8, takže snad brzy vyjde.

[unchallenger]

A soudě podle konrefence raději i na Gtk+ 2.8.1... nebo ho vzít z CVS.