Hi,

So, I've recently switched from gimp 2.6 to gimp 2.8, and I found that the time taken to draw gradients is far longer in 2.8 than in 2.6

To test, I made a blank black canvas at 1024px, then drew a radial gradient from center to edge. 2.6 drew it in under a second. 2.8 took 8.7 seconds to complete.

Is this something that others have noticed?

Yes, I can reproduce it with the 2.8 builds for Mac and Windows. The slowdown does not only affect the blend tool. This seems to be related with color management. In the Windows version you can speedup the blend tool among some other things by disabling the color management filter in View/Display filters.... This does a speedup for me, but it's only a temporary solution, as this only affects the currently open picture and only for this session. Also see bug #645345 in Bugzilla for a similar problem.
It's the same problem with the Mac version. 2.8 is slower than 2.6, but unfortunately the View/Display filters... trick doesn't work there.

Is it a result of the move to GEGL?

I think so.

Will it be fixed?

I hope so. This bug tempers the GIMP 2.8 honeymoon and I'm already thinking of staying with 2.6 for production or further using PS.

Or, the other way around: never switch to x.0 versions... ;-)

Best regards,

grafxuser

On Fri, 2012-05-11 at 06:57 -0700, C55inator wrote:

So, I've recently switched from gimp 2.6 to gimp 2.8, and I found that the time taken to draw gradients is far longer in 2.8 than in 2.6

To test, I made a blank black canvas at 1024px, then drew a radial gradient from center to edge. 2.6 drew it in under a second. 2.8 took 8.7 seconds to complete.

Is this something that others have noticed? Is it a result of the move to GEGL? Will it be fixed?

GIMP 2.8 is not ported to GEGL.

If I try this on git master (which IS ported to GEGL), it takes much less than a second on my linux machine, and is even faster on my Mac, even though there is zero threading and only one processor used.

I don't currently have 2.8 installed on this Mac, but it can hardly be slower, unless the threading got broken in GLib, try to set #processors to 1 in prefs and try again.

Also, what build are you using? Native or X11?

--Mitch

Hi,

On 2012-05-11.12 Michael Natterer wrote:

I don't currently have 2.8 installed on this Mac, but it can hardly be slower, unless the threading got broken in GLib, try to set #processors to 1 in prefs and try again.

thanks Mitch, for your reply.
You're right, on the Mac it depends on the number of processors. Varying this number in the preferences dialog between 1 and 16 showed significant differences. The operation takes 1 second if #processors is set to 1 and about 8 seconds if it's set to 16 processors. BTW: my Mac has 1 processor with 2 cores. It's quite pointless to be able to set #processors in prefs to 16. The upper bound for the input value should be the actual number of processors or cores. Is this a known issue or shall I file a new bug in Bugzilla?

Also, what build are you using? Native or X11?

How can I find this out? I used the fresh 2.8 version from gimp.lisanet.de. When running GIMP, the X window is open, too. So I'm sure it's the X11 build. How could I otherwise find out whether the Mac build is native?

Best regards,

grafxuser

The native Mac build has the menu all on the top just like all other Mac apps.

On Fri, May 11, 2012 at 5:01 PM, gfxuser wrote:

Hi,

On 2012-05-11.12 Michael Natterer wrote:

I don't currently have 2.8 installed on this Mac, but it can hardly be slower, unless the threading got broken in GLib, try to set #processors to 1 in prefs and try again.

thanks Mitch, for your reply.
You're right, on the Mac it depends on the number of processors. Varying this number in the preferences dialog between 1 and 16 showed significant differences. The operation takes 1 second if #processors is set to 1 and about 8 seconds if it's set to 16 processors. BTW: my Mac has 1 processor with 2 cores. It's quite pointless to be able to set #processors in prefs to 16. The upper bound for the input value should be the actual number of processors or cores. Is this a known issue or shall I file a new bug in Bugzilla?

Also, what build are you using? Native or X11?

How can I find this out? I used the fresh 2.8 version from gimp.lisanet.de. When running GIMP, the X window is open, too. So I'm sure it's the X11 build. How could I otherwise find out whether the Mac build is native?

Best regards,

grafxuser

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, 2012-05-11 at 23:01 +0200, gfxuser wrote:

Hi,

On 2012-05-11.12 Michael Natterer wrote:

I don't currently have 2.8 installed on this Mac, but it can hardly be slower, unless the threading got broken in GLib, try to set #processors to 1 in prefs and try again.

thanks Mitch, for your reply.
You're right, on the Mac it depends on the number of processors. Varying this number in the preferences dialog between 1 and 16 showed significant differences. The operation takes 1 second if #processors is set to 1 and about 8 seconds if it's set to 16 processors. BTW: my Mac has 1 processor with 2 cores. It's quite pointless to be able to set #processors in prefs to 16. The upper bound for the input value should be the actual number of processors or cores. Is this a known issue or shall I file a new bug in Bugzilla?

Please file it in bugzilla, it's pointless to use threading if it makes things slower, and we have no code to determine the #cpus on the mac anyway, so we should default to one.

Also, what build are you using? Native or X11?

How can I find this out? I used the fresh 2.8 version from gimp.lisanet.de. When running GIMP, the X window is open, too. So I'm sure it's the X11 build. How could I otherwise find out whether the Mac build is native?

As Partha said :)

Regards,
--mitch

El 11/05/12 20:21, Michael Natterer escribi:

Please file it in bugzilla, it's pointless to use threading if it makes things slower, and we have no code to determine the #cpus on the mac anyway, so we should default to one.

My 2.9 install on linux (Debian, 64 bit) also detected the number of cpus incorrectly. I'm using a Quad Core and it defaulted to 8 threads and it also made some things slower. 2.8 worked fine though, it's set to 4 threads and I can't notice any slowness because of that.

Gez.

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Partha Bagchi wrote (was: Re: [Gimp-developer] Gimp 2.8 blend time)

The native Mac build has the menu all on the top just like all other Mac apps.

Thanks. Until now I didn't know of the native Mac build at all. Are these the versions from Macports or Fink? Where can I get it from, otherwise?
I always used Simone's build (gimp.lisanet.de) and was quite lucky with it. But currently there's a bug with the curves tool (bug #675906), which makes photo editing with GIMP harder and I'd like to check this with the native version, too.

Thanks, grafxuser

So, I've recently switched from gimp 2.6 to gimp 2.8, and I found that the time taken to draw gradients is far longer in 2.8 than in 2.6

To test, I made a blank black canvas at 1024px, then drew a radial gradient from center to edge. 2.6 drew it in under a second. 2.8 took 8.7 seconds to complete.

Is this something that others have noticed? Is it a result of the move to GEGL? Will it be fixed?

I just tried this on 2.9 (SUSE) and it did it in less than a second.

However all the "Shaped" gradients took ages, like a minute or more compared to a few seconds in 2.6

On Sat, 2012-05-12 at 00:16 -0300, Guillermo Espertino (Gez) wrote:

El 11/05/12 20:21, Michael Natterer escribió:

Please file it in bugzilla, it's pointless to use threading if it makes things slower, and we have no code to determine the #cpus on the mac anyway, so we should default to one.

My 2.9 install on linux (Debian, 64 bit) also detected the number of cpus incorrectly. I'm using a Quad Core and it defaulted to 8 threads and it also made some things slower. 2.8 worked fine though, it's set to 4 threads and I can't notice any slowness because of that.

Ignore any threading in 2.9, it's all going away and transparently handled by GEGL/OpenCL.

--Mitch

On Sat, 2012-05-12 at 15:11 +1000, Owen wrote:

So, I've recently switched from gimp 2.6 to gimp 2.8, and I found that the time taken to draw gradients is far longer in 2.8 than in 2.6

To test, I made a blank black canvas at 1024px, then drew a radial gradient from center to edge. 2.6 drew it in under a second. 2.8 took 8.7 seconds to complete.

Is this something that others have noticed? Is it a result of the move to GEGL? Will it be fixed?

I just tried this on 2.9 (SUSE) and it did it in less than a second.

However all the "Shaped" gradients took ages, like a minute or more compared to a few seconds in 2.6

Known problem with GimpOperatrionShapeburst, will be fixed.

--Mitch