GIMP 2.10 is very slow? Any ideas?

Software GIMP
1

Hi Everyone,

First-time poster, long-time follower of the site. Thanks to everyone who put in such an effort on this site, it’s a great place to find answers and tips!

I just downloaded and installed GIMP 2.10 and I was really excited to be able to work with 16-bit TIF files straight out of RawTherapee (helps with my work flow). However, I’m disappointed to see how extremely slow loading the XCF file and adding layers to the project seems to be. The file takes 25 seconds to load, for example, and adding a duplicate layer takes between 1-2 seconds. 8-bit images seem to work normally.

I’m running a Win10, i5 2.7GHz machine, not exactly what I would call a slow machine, but maybe also not the fastest. In any case, I would think it should work just fine, no? Anyone else having this problem? Are the Preferences that I should change regarding memory usage?

Thanks in advance!
Cheers,
Daniel

2

Just coming back to this to see if really no one else here is experiencing a very slow Gimp 2.10. I’ve found the same issue I have on at least 2 other forums, with not much of an answer as to why or what to do. As Pixls.us is dedicated to open source photography software, I hope that someone out there might have a suggestion, especially since many developers are here as well.

In the end, it is not just 16-Bit but also 8-bit images running slow (although, 16-bit is really bad). I have updated the graphics driver, I have 8GB RAM and all other imaging software runs smoothly on my machine. I have OpenCL turned on in Gimp.

Any help would be greatly appreciated!!

3

Yes, it’s slow when it comes to 16 bit pictures. Especially, if you are post processing heavier photos. So, the same problem here.

4

:thinking: Weird, I have an old low end (maybe dying) laptop and GIMP has been running better before. In fact any slowdowns from before have been rectified. Have you tried the copy from partha.com? That is the build that I have been using.

5
  1. The lower the precision of the image (bit depth), the less data to work with. It’s normal for an 8-bit image to load faster than a 16-bit one.
  2. The engine works in 32-bit precision regardless of image bit depth.
  3. It was advised to work in 32-bit precision instead of 16-bit to avoid conversion delays in 2.9.4. A GIMP dev would need to chime in whether this is still the case for 2.10.
  4. Color management will cause a delay in updating the preview, painting, etc. Turn it off if you’re not working with color.
  5. Report issues in GIMP’s bug tracker.
6

Do you also notice a slowdown when working with 8-bit? When I originally posted it seemed to be working, but then realized the problem persisted even with 8-bit, albeit not as bad.

7

I’m going to check that out now! Thanks!

EDIT: I’m not very in-the-know regarding different builds of open source software. Is the @partha build simply a different take on the official release?

8

Thanks for the these tips. I will try it and see. If the problem persists, I’ll report it.

9

Yeah; posted about how the slow the Script-fu Luma Invert was compared to how it use to be. It maybe just be isolated to Script-fus though since I’ve not noticed plugins running slow. :slight_smile:

10

I’ve just change to portable partha’s build. It’s a lot faster and I have no clue why.

11

I installed the standard version, and seems much better. Except now, I’ve gotten twice a GEGL swap folder error when painting on an image. I’ll monitor that but otherwise thank you for the suggestion.

12

Got that as well, what seemed to fix it was changing the swap file location in settings to a folder / drive that actually exists

13

Preferences → Folders → Swap Folder to be exact, was set to something odd, so i changed it, and then the swap error went away

1 Like
14

Please please please report this upstream, i.e. to https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP
Even if it’s something as silly as a wrong default, it must be reported in the right place so that it can be fixed/improved for everyone. Open-source stays alive by giving back. If you find a solution which works for you but you don’t report it upstream, everyone else will still be stuck with that problem. Give back through reporting issues in the correct place.

15

Hi Morgan,
I just added to an already existing bug report there (or at least one which was similar). Thanks for that link, really appreciate that. Do you happen to know if I should already report the Swap error for the @partha build? Same place?

16

I check that too, it is already pointing to a folder that exists: Users/Name/AppData/Roaming/GIMP/2.10

Where was yours pointing to?

17

@drhphotography negative, @partha’s builds are not suported by upstream (unless the issue is also in upstream), and he can see your report here when you @ mention him, so all good.

1 Like
18

I take that back, in 16 and 32 bit color the swap error rears its ugly head, this occurs in Parthas and Standard Gimp2.10

19

Bonjour,

I greatly improve speed by validating OpenCL (from 227 seconds to 36 seconds of processing on very large images).
It depends on the hardware installed on your computer.
O.S. Win 10 pro 64 bit.

I noticed that some operations are much faster using 32-bit versions (gimp.org, PortableApps, GimpEval)… It’s weird.

:o)

20

It happened to me again today :frowning: