RSS/Atom feed Twitter
Site is read-only, email is disabled

Why is GIMP 1.3.x user interface much slower than 1.2.x?

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.

Why is GIMP 1.3.x user interface much slower than 1.2.x? Rapha 24 Apr 14:05
  Why is GIMP 1.3.x user interface much slower than 1.2.x? Sven Neumann 24 Apr 15:26
   Why is GIMP 1.3.x user interface much slower than 1.2.x? Rapha 24 Apr 16:08
    Why is GIMP 1.3.x user interface much slower than 1.2.x? Sven Neumann 24 Apr 17:49
Rapha
2002-04-24 14:05:55 UTC (almost 22 years ago)

Why is GIMP 1.3.x user interface much slower than 1.2.x?

This is something that has been bothering me for a while, and maybe I am not the only one who has noticed this. I have compiled the CVS HEAD version and the 1.2.3 version on the same old machine (a Pentium 200) and the CVS version is significantly slower than the 1.2.x version. Of course, there is a lot of debugging code in 1.3.x, but I am surprised that the differences are so significant on that machine.

Some simple operations such as accessing the menus (both the pop-up menus and the menus from the toolbox), refreshing the toolbox or refreshing the contents of the docks take approximatively 5 to 6 times longer than with the old 1.2.3 version. The delays are significant enough to disturb the normal flow of operations (at least for me).

Does anybody know what could be the source of these delays? Is this due to the GIMP itself (debugging code, new user interface) or is this due to the fact that the CVS version uses GTK+ 2.0 instead of GTK+ 1.2.x?

-Raphaël

Sven Neumann
2002-04-24 15:26:05 UTC (almost 22 years ago)

Why is GIMP 1.3.x user interface much slower than 1.2.x?

Hi,

RaphaXl Quinet writes:

This is something that has been bothering me for a while, and maybe I am not the only one who has noticed this. I have compiled the CVS HEAD version and the 1.2.3 version on the same old machine (a Pentium 200) and the CVS version is significantly slower than the 1.2.x version. Of course, there is a lot of debugging code in 1.3.x, but I am surprised that the differences are so significant on that machine.

Some simple operations such as accessing the menus (both the pop-up menus and the menus from the toolbox), refreshing the toolbox or refreshing the contents of the docks take approximatively 5 to 6 times longer than with the old 1.2.3 version. The delays are significant enough to disturb the normal flow of operations (at least for me).

Does anybody know what could be the source of these delays? Is this due to the GIMP itself (debugging code, new user interface) or is this due to the fact that the CVS version uses GTK+ 2.0 instead of GTK+ 1.2.x?

Hard to say. It's been said that GTK+-2.0 is substantially slower than 1.2. I don't notice much difference here but then my machine is probably fast enough. Have you played with testgtk; do you notice the same problems there?

Of course GIMP-1.3 has lots of room for improvement. One thing that is on our TODO is to change GimpPreview so it can use GdkPixbuf directly. We'd avoid the conversion to TempBuf and could use the (optionally hardware accelerated) pixbuf render routines.

Since we use a model-view concept in GIMP-1.3, we use a lot of signal emissions to synchronize the UI with the core data structs. You could get a noticeable speedup by compiling glib without debugging (default since 2.0) and make sure that app/core/gimpmarshal.[ch] is generated using a recent version of glib-genmarshal. Newer versions access the GValues used in signal emissions directly instead of going thru extensive type checks. Basically you should have some code like this in app/core/gimpmarshal.c:

#ifdef G_ENABLE_DEBUG #define g_marshal_value_peek_boolean(v) g_value_get_boolean (v) #else
#define g_marshal_value_peek_boolean(v) (v)->data[0].v_int #endif

For further optimizations we should do some profiling first since it doesn't make sense to remove useful debugging code unless it shows up significantly in the profile.

Salut, Sven

Rapha
2002-04-24 16:08:37 UTC (almost 22 years ago)

Why is GIMP 1.3.x user interface much slower than 1.2.x?

On 24 Apr 2002 15:26:05 +0200, "Sven Neumann" wrote:

Raphaël Quinet writes:

Does anybody know what could be the source of these delays? Is this due to the GIMP itself (debugging code, new user interface) or is this due to the fact that the CVS version uses GTK+ 2.0 instead of GTK+ 1.2.x?

Hard to say. It's been said that GTK+-2.0 is substantially slower than 1.2. I don't notice much difference here but then my machine is probably fast enough. Have you played with testgtk; do you notice the same problems there?

Yes, I have played with testgtk in both versions. Unfortunately the interface has changed so it is hard to compare the performance in both cases. The new one from GTK+ 2.0 is definitely slower, but it is difficult to say if that would explain the difference seen in the GIMP.

Maybe I need to find an even slower computer than my PC at home, so that I can compare how fast GTK+ 2.0 redraws its widgets compared to 1.2.x.

Since we use a model-view concept in GIMP-1.3, we use a lot of signal emissions to synchronize the UI with the core data structs. You could get a noticeable speedup by compiling glib without debugging (default since 2.0) and make sure that app/core/gimpmarshal.[ch] is generated using a recent version of glib-genmarshal.

Yes, I also get glib and gtk+ from anonymous CVS (updated during the week-end) so I should have the correct version.

For further optimizations we should do some profiling first since it doesn't make sense to remove useful debugging code unless it shows up significantly in the profile.

Of course! It is much too early to remove the debugging code from CVS HEAD and it would be foolish to start optimizing anything before the code is reasonably stable. And, as you pointed out, no optimization should be attempted before having a good profiling report. I was not trying to find a way to improve the speed of the current GIMP 1.3.x (not yet, at least), but I was curious to know if anybody had an idea about what was making it so slow.

-Raphaël

Sven Neumann
2002-04-24 17:49:34 UTC (almost 22 years ago)

Why is GIMP 1.3.x user interface much slower than 1.2.x?

Hi,

RaphaXl Quinet writes:

Yes, I have played with testgtk in both versions. Unfortunately the interface has changed so it is hard to compare the performance in both cases. The new one from GTK+ 2.0 is definitely slower, but it is difficult to say if that would explain the difference seen in the GIMP.

Maybe I need to find an even slower computer than my PC at home, so that I can compare how fast GTK+ 2.0 redraws its widgets compared to 1.2.x.

GTK+-2.0 draws its widgets double-buffered which definitely does not make it faster (but reduces flickering). It might be interesting to disable this feature by undefining USE_BACKING_STORE in gdkwindow.c.

Since we use a model-view concept in GIMP-1.3, we use a lot of signal emissions to synchronize the UI with the core data structs. You could get a noticeable speedup by compiling glib without debugging (default since 2.0) and make sure that app/core/gimpmarshal.[ch] is generated using a recent version of glib-genmarshal.

Yes, I also get glib and gtk+ from anonymous CVS (updated during the week-end) so I should have the correct version.

gimpmarshal.[ch] might nevertheless not have been rebuilt since there's no dependency to glib-genmarshal. You better have a look at the files or touch gimpmarshal.list to force regeneration.

Salut, Sven