Performance regression in GTK+ 2.0 compared to 1.2?
- From: ERDI Gergo <cactus cactus rulez org>
- To: gtk-list gnome org
- Subject: Performance regression in GTK+ 2.0 compared to 1.2?
- Date: Tue, 21 May 2002 12:55:11 +0200 (CEST)
[please CC replies to cactus cactus rulez org, thanks]
Since GTK+ 2.0 has been released for more than a month, I decided to get
up-to-date with GTKmm and other related packages to fix Gnomoku which has
surely bit-rotten in the last months. Back when I first ported it to GTK+
1.3, it was very slow, but that was before 2.0 so I guessed it had al
kinds of debug code and unoptimized code paths and whatnot.
However, now I see the same performance problems compared to GTK+ 1.2:
Gnomoku uses a 15x15 grid of GtkButtons (which should be a good
stress-test), and with GTK+ 1.2 the redrawing occurs instantly (when
raising it from below another window or resizing it for example), but with
GTK+ 2.0 it takes a visible amount of time for the updating to occur,
especially for the resizing case. I've also tried gconf-editor: when the
window is maximized and I drag the vertical separator handle, huge gray
areas can be seen flickering.
I've installed the GTK+ 2.0 and related packages from Debian so they
aren't compiled with debug flags; the exact version is 2.0.2.
So I'm looking for ideas where I should look for finding misconfiguration
in my setup. I don't use GDK's XFT support, the theme is the default one.
I'd say everything related to GTK+ 2 is set to the default, so I have no
idea what's causing this.
Any ideas welcome,
Gergo
--
.--= ULLA! =---------------------. `We are not here to give users what
\ http://cactus.rulez.org \ they want' -- RMS, at GUADEC 2001
`---= cactus cactus rulez org =---'
Szabadság, szerelem -- ext2 kell nekem
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]