This is a development release leading up to GTK+ 2.4. Changes since GTK+ 2.3.0 consist of numerous small bug fixes and enhancements, with a special focus on the new GtkFileChooser. Glib, Pango announcements. On other Gnome/GTK+ news, Gnomemeeting 0.99 was released today too (review).
Development Version GTK+ 2.3.1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Not trolling, but is 2.4 dramatically faster than 2.2? GTK2 apps are glacially slow on my system. List views, in particular, are an order of magnitude slower. JuK has no problem handling thousands of items in the list view, while GtkPod starts feeling pokey at a few hundred. Also, resizing is abysmal. I can understand Epiphany vs Konqueror, because Gecko is pretty pokey on every OS I’ve used it, but KSpread resizes faster than Gnumeric, and Kate resizes faster than Gedit. Using GNOME 2.4, I see expose lag everywhere (especially in Evolution 1.4).
I thought I heard a rumor that that this had something to do with a (mis)use of XRender and was being fixed, but I have no facts to substantiate that idea. I don’t even remember where I read it. Also, I have this weird problem. In Fedora, resizing GTK apps is pretty good (until the window size exceeds 1200×900 anyway), but only if I use the ‘nv’ driver. Using the ‘nvidia’ driver (which, by my benchmarks, is a whole lot faster), stuff becomes glacial again.
i seem to recall hearing something about a problem with the nVidia binary drivers for X, can’t remember what exactly though.
Obligatory GtkFileChooser screenshot request:
“Let us see what it really looks like – please!!”
So how’s the Gnome version numbering with respect to GTK’s go? Will there be a new generation GTK 3 on which Gnome 3 will be running?
It’s not just you. As I mentioned in the article about KDE 3.2 beta I find it surprising that the supposed bloated c++ desktop is much quicker than the lean and mean gtk+ based desktop. Eugenia has mentioned this before too and I’ve never found the explanation, but it’s b.s.
It’s not just the nvidia driver, there is something else going on. Gtk+1.2 was nice and quick.
I think when people say GTK is quicker than KDE apps, they are not talking about resize performance. GTK is double buffered and this seems to be the reason it can get slow on redraws. The new X should fix this though. Its more of an X issue it seems. But take this with a grain of salt, I am not really qualified to say.
I don’t think much optimizations have gone into GTK+ and related libs. However, I don’t experience those resize issues as explained above. As GTK+ and related libs become more optimized, expect improvement in performance. I don’t think the devs are concentrating on optimization at the moment either.
Oh, and I don’t care what you say, GNOME’s memory footprint is much smaller than KDEs.
Did they rename the “Frobnicate” checkbox so one knows what it means now?
I think that was just a test file selector. Its a development version, a very early one at that, so expect a lot of easter eggs. That one was just to test the API and make sure it is working well. It may evolve into the final thing though.
I believe the frobnicate checkbox was just an example showing that you could tweak the window and add custom widgets easily.
I do like the GTK+ widget set and I hope they have improved the performance: it is rather sluggish.
This performance issue becomes apparant when a large list view is loaded, such as over 2000 entries. As a result, the list takes forever before it is shown. Then, in addition, the resizing of fields becomes very sluggish.
Anyway, I can say that GTK is a very nice collection of widgets, but it needs optimisation at some major spots.
> This performance issue becomes apparant when a large list
> view is loaded, such as over 2000 entries.
Do you have an example with any well-known application? Nautilus uses the TreeView and does not have this problem. It is possible to make a slow TreeView, but this is not necessarily GTK+’s fault.
I thought I heard a rumor that that this had something to do with a (mis)use of XRender and was being fixed, but I have no facts to substantiate that idea. I don’t even remember where I read it. Also, I have this weird problem. In Fedora, resizing GTK apps is pretty good (until the window size exceeds 1200×900 anyway), but only if I use the ‘nv’ driver. Using the ‘nvidia’ driver (which, by my benchmarks, is a whole lot faster), stuff becomes glacial again.
This is indeed a problem with the nVidia driver. I don’t know exactly where I read about it and can’t check it out right now, but I suggest you go look at the forum at http://www.gnomedesktop.org
Qt is double-buffered too, and it resizes fine. To really get an impression of how slow GTK+ is, load 1000 MP3s into gtkpod then 1000 mp3s in JuK. Then test operations like sorting and resizing columns. Its *way* slower. Qt’s list view is instant, GTK’s is very laggy.
Qt is double-buffered too, and it resizes fine. To really get an impression of how slow GTK+ is, load 1000 MP3s into gtkpod then 1000 mp3s in JuK. Then test operations like sorting and resizing columns. Its *way* slower. Qt’s list view is instant, GTK’s is very laggy.
And how do we know that is GTK+’s fault and not gtkpod? Try using jamboree to load your mp3’s instead.
You also make it sound like GTK+ is unbearably slow. It is not. There are some size issues here and their but most problems stem from application developers not from GTK+ itself. I suppose Mike Hearn describes the situation best.
“No, it is not possible to disable double buffering.
Part of the problem is that people judge “speed” by a few very specific factors – for instance, opaque resize and move performance.
In Fedora, there are hacks to try and improve that, and they work a bit but the real solution lies in the X server (kdrive in particular).
I suggest you fire up gtk-demo at some point, then try moving the splitters around. This causes the window to be re-rendered but it does *not* involve resizing X windows (at least, not much). I think you’ll be surprised at how smooth it feels, I know I was.
I think GTK+ is slightly slower at drawing than Qt but that’s primarily because GTK+ double buffers everything (makes some things faster and smoother, ie there is no flicker, but other things a bit slower), and GTK+ has more advanced widget containment and text rendering subsystems which eat more CPU time.
I don’t find the speed of GTK+ a problem, and besides, in future double buffered X windows will make the toolkit speed less of an issue. Things like the quality of the widgets, the beauty of the stock artwork (of which Qt has little to none) and so on make or break a widget toolkit for me. I find GTK+ better in these regards as a user.
Oh, finally, I dunno where ChocolateCheeseCake got the idea that GTKmm is less featureful than the GTK+ C bindings. IIRC GTKmm wraps 2.2 just fine, and there is even a version that does 2.4 – personally I think people bitching about the GTK+ API or “technology” are typically back seat coders who don’t actually do that much. At least, I see lots of GTK apps out there, so if it really was as bad as some make out, why do we see so many?”
“Qt is double-buffered too, and it resizes fine. To really get an impression of how slow GTK+ is, load 1000 MP3s into gtkpod then 1000 mp3s in JuK. Then test operations like sorting and resizing columns. Its *way* slower. Qt’s list view is instant, GTK’s is very laggy.”
The problem is not how the list works but how the program is filling the list. I’m using Rythmbox 0.6 and I can tell you that it loads 3000 songs in less than a second (just to give a number). So the problem is in the program and not in GTK+
You also make it sound like GTK+ is unbearably slow.
>>>>>>>>>
It is unbearably slow, for me anyway. I used to be a BeOS user
Seriously, though, the slowness is the major reason I never really got into using GNOME 2.x.
Its not about how long it takes to load, but how smooth manipulation is. Let me use Rhythmbox (with about 100 loaded items) as an example:
– Resizing lags *way* behind the window frame. Its just a few simple widgets, but lags behind *Konqueror* displaying a complex page like Slashdot. The toolbar also creeps across the screen, redrawing only two or three times before it gets all the way across.
– Moving a window over Rhythmbox’s will leave a significant
white streak behind as the expose gets processed.
– Grabbing a column-header and moving it back and forth causes the column to lag behind the mouse very significantly. JuK won’t do this even with over a thousand items loaded. In KDE List Views, the column header always stays right under the mouse.
– Moving the vertical pane divider between the source list and the track list not only lags, but causes the columns to jerk back and forth as they reposition themselves.
Maybe its just my machine (2GHz P4, kernel 2.6), but to tell the truth, using GTK apps always makes me feel like those “X is slow” people are right…