Around the Planet

Try out the latest Gnome 2.9.x panel and applets packages (or use CVS). Many of the applets should now display correctly with pattern backgrounds (which includes transparency).

GTK isn't a processor hog, at least on all the systems I've tried it on (from a k6-2 300 mhz to a centrino 1500). Although rendering could be faster. And that's being worked on:

First, the XRender implementation in X.Org is being optimized, as the prior XFree86 one was awfully implemented (as pointed out by enlightenment developer rasterman).

Second, pango is getting an alternative rendering pipe for western characters, that should boost text rendering speed on most systems.

>First, the XRender implementation in X.Org is being optimized, as >the prior XFree86 one was awfully implemented (as pointed out by >enlightenment developer rasterman).

So why Qt is much faster than Gtk? Qt uses XRender too...

>Second, pango is getting an alternative rendering pipe for western
>characters, that should boost text rendering speed on most systems.

Yes, maybe.
But.. Have you tried opening a folder with 1.000+ files in it? Try that, compare Qt and Gtk, and then tell me. It is not only pango's fault.

>So why Qt is much faster than Gtk? Qt uses XRender too...

Qt developers wrote some parts of the drawing code not to use XRender, because of the problems of XRender implementation. It really shows up when it comes to font rendering.

>But.. Have you tried opening a folder with 1.000+ files in it? Try that, compare Qt and Gtk, and then tell me. It is not only pango's fault.

Opening a folder with 1000+ files and it showing slow is not (90% of the time) problem of the graphic toolkit, but the way data is read from disk. Anyway, I've tried it with nautilus 2.6 in spatial mode (directory /dev, more than 1600 files) and it shows faster than konqueror. Like 2 seconds to display all the files in a blaze, in a k7@700.

i tried with a folder with ~7000 files in it
under wxp explorer loads it in ~2 seconds
under kde, konqueror (3.2) loads it in ~6 seconds
under gnome, nautilus (2.6) loads it in ~11 seconds
the bad timing under linux maybe it's because the folder is a mounted fat32 partition, i don't know.
still, nautilus is almost twice slower than konqueror

pentium 4 1.7 mhz

GTK2 has been a processor hog on all the systems I've tried it on. You need an app like gtk-gnutella -- it has different front ends. The GTK2 one hogs the processor like nothing else (even though it's not poorly written or anything like that), while the GTK1 front end uses virtually nothing. This has been true for every app with GTK1/2 versions... and for the entire lifetime of GTK2.

GTK2 continues to hog processor time, and is... to put it mildly... an unoptimised mess and sucks donkey balls.

From the look of it, the GTK2 frontend of gtk-gnutella uses the new GtkTreeView widget while the GTK1 frontend uses a clist.

Given that these are quite different APIs, making a direct comparison is not easy.

As there are a large number of applications using GtkTreeView and are not CPU hogs, perhaps the problem lies in the gtk-gnutella code?

The most likely problem is that it is triggering needless updates. For example, updating a row with exactly the same data, removing/adding rows when not needed, etc.

> The GTK2 one hogs the processor like nothing else (even though it's not poorly written or anything like that)

Mandatory screenshot:

http://gtk-gnutella.sourceforge.net/images/shots/092/gnutellaNet-Stats-GTK2.png

The C source for that screen actually starts with 6 declarations of GTKTreeViews, the most resource intensive widget in GTK2. The GTK1.2 equivalent source for that screen uses CLists instead (much lighter).

It's actually surprising you didn't find it weird for gtk-gnutella to be such a resource hog when programs like evolution (with a more sophisticated UI) hop merrily around. I at least did, that's why I switched to mutella.

Of course, the GTK2 UI should be somewhat slower even with equivalent widgets. The addition of unicode support and accessibility to the toolkit comes at a price (logically).

The rest of your post is too trollish to be worthy of some reasoned answer by anyone.

Mandatory screenshot:

Furthermore: that's a config page you are looking at. GTK2 is a hog on gtk-gnutella even when that page isn't open. So take you fantasyland defense of GTK2 elsewhere.

>Furthermore: that's a config page you are looking at. GTK2 is a hog on gtk-gnutella even when that page isn't open. So take you fantasyland defense of GTK2 elsewhere.

Nope. I don't know what's wrong with your sight (or mind), but that is a "status" window, that gets refreshed constantly. Says so in the url, and clearly shows in the screenshot.

Now, if you're just being stubborn to show how much you hate GTK2, power to you. But facts are objective, not subjective :)

that gets refreshed constantly.

No. It. Doesn't. Chimpwit. If you have the status open it does... if not, it doesn't.

why ?

It's actually surprising you didn't find it weird for gtk-gnutella to be such a resource hog when programs like evolution (with a more sophisticated UI) hop merrily around.

I'm sorry... what? Evolution "hops merrily" around. In what universe are you living? I'm starting to wonder whether you actually use any GTK2 apps or just make stuff up to defend it against disgruntled users who *do* have to put up with its awfulness.

Of course, the GTK2 UI should be somewhat slower even with equivalent widgets. The addition of unicode support and accessibility to the toolkit comes at a price (logically).

Stuff and nonsense -- argument by assertion. Lots of toolkits (starting with Qt) support unicode without the dreadful slowness (and don't come back with the crap about Xrender -- its a big red herring). As for gtk-gnutella having 6 treeviews? Oh wow... well, let's let everyone know what you can take up 15% of the processor on an athlon 1.6Ghz Athlon just by declaring 6 tree views in your user interface. That's perfectly normal and acceptable. Yes sir!

>I'm sorry... what? Evolution "hops merrily" around. In what universe are you living? I'm starting to wonder whether you actually use any GTK2 apps or just make stuff up to defend it against disgruntled users who *do* have to put up with its awfulness.

In my "fantasy world", I must use daily outlook and evolution2, and evolution2 only shows delays on vfolder operations and net ones. The gtk2 part is blazing fast. And evolution2 performs overall much better than outlook on my systems.

>Stuff and nonsense -- argument by assertion. Lots of toolkits (starting with Qt) support unicode without the dreadful slowness (and don't come back with the crap about Xrender -- its a big red herring). As for gtk-gnutella having 6 treeviews? Oh wow... well, let's let everyone know what you can take up 15% of the processor on an athlon 1.6Ghz Athlon just by declaring 6 tree views in your user interface. That's perfectly normal and acceptable. Yes sir!

1) Qt doesn't get the same accessibility level than GTK at all. Actually, KDE developers will use the ATK part in gnome for future KDE accessibility. And you can ignore the XRender issue as much as you want, rasterman already showed how an implementation that rewrites XRender functions using imlib and so boosts performance up to 30x.

2) The problem is not *declaring* 6 treeviews, it's *updating* 6 treeviews constantly when they aren't required to perform the same function, as much lighter widgets would do.

But well, if you hate GTK2's speed you could help by doing some profiling and helping the developers.

But just by reading your irrational, hateful, stubborn posts, it's clear that you'll just troll about it instead. Wether it's because you don't like the way GTK2 works, or because you are a (insert-other-toolkit) fanboy, it's not clear neither important at all.

Qt doesn't get the same accessibility level than GTK at all.

So now it's accessiblity that's slowing GTK2 down. What's next... phase of the moon. Look, you ignored the main point that small treeviews (not loaded with huge amounts of data) take a big chunk of the processor on a fairly fast machine (with 512Mb) of RAM. Make all the excuses you like and try to obfuscate... it doesn't change the facts.

2) The problem is not *declaring* 6 treeviews, it's *updating* 6 treeviews constantly when they aren't required to perform the same function, as much lighter widgets would do.

No. They. Are. Not. Good lord! According to you it's the drawing and XRender that's slow... and yet when they aren't drawn GTK2 is still SLOW. Which is it?

Your claims about GTK2 being blazingly fast (and faster than Windows -- you mentioned outlook) are simply a joke. I've used GTK2 on a variety of machines, it has always been slower than any comparible windows machine.

the main problem in many GTK2 applications is the BAD use of gtk2

also GTK2 relies on some Xrender code which NOT fast

trolltech smarter choose to no use xrender and rewrite some code for their QT

also, you don't want to read that, but Evolution 2 is not a "processor hog" (but its use of spamasssassin for me is a processor hog, not the ui and reactivity in general)

Nautilus 2.6 and 2.8 is really fast even in /dev filled with thousand files. I have also better experiences with nautilus than konqueror

but I can find many many KDE/QT applications better write than some GTK counterparts.

in summary :
GTK 2 have some limitations, but NOT horrible as you say, and :

SLOWNESS in APPLICATION IS NOT SIMPLY TOOLKIT ! there are many possibility of uses of the toolkit and MANY others librairies in use.

profiling and debug information should the better answer if you feel a "gtk is scarp" urge.

and please, he never say GTK 2 was "faster than windows", he speak about evolution against outlook. evolution 2 is for him a GOOD example of GTK2 use.

(and it's true evolution 2 is not slow, despite pango, utf8, atk accessibility, anti-aliasing and many stuff NOT in gtk 1)

no need to be angry. people are working to do better and I sincerely NOT have "processor hog" when I use some GTK2 applications (no it's not a blazing modern Pc I have).

Profiling is the better thing to do to help.

I'm just wondering what the meaning of this exchange was? I have no idea what galago is and I have no idea why you responded with so much hostility. I'm not agreeing/disagreeing with either of you. I just really have no idea what either of you are talking about and I am curious.

Info on Galago is here: http://galago.sourceforge.net/about.php
Screenshots of what it can do here: http://galago.sourceforge.net/screenshots/index.php

That was my post pointing out that Galago is undergoing active development. Since it's one of the most exciting things going on wrt Gnome for me, I figured I'd point it out.

Now the great-grandparent of this post was talking about how GTK is a processor and memory hog. The poster offered nothing to back up his claim other than wild allegations, so someone got cranky and responded harshly.

Hope that helps :)

About: http://galago.sourceforge.net/about.php

Samples of what it can do: http://galago.sourceforge.net/screenshots/index.php

luminocity sounds very nice...

That I did.......Added.