GIMP 2.10 is very slow? Any ideas?

Software GIMP
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:

21

Hello, I have same problem too. There is something on the official build because Parthas build is much, much faster.

Official GIMP build:
It takes about 38 seconds to open the image and draw it to canvas.

Adjust curves (without preview) takes about 1 minute and 34 seconds to complete the process and redraw canvas. CPU usage is about 30% and GPU usage jumps between 4-10%.

Rotating tool takes about 2 minutes and 20 seconds to complete the process and redraw canvas. CPU usage is about 70% and GPU usage jumps between 0-40%.

Parthas build:
It takes about 11 seconds to open the image and draw it to canvas.

Adjust curves (without preview) takes about 18 seconds to complete the process and redraw canvas. CPU usage is about 30% and GPU usage jumps between 4-10%.

Rotating tool takes about 20 seconds to complete the process and redraw canvas. CPU usage is about 70% and GPU usage jumps between 0-40%.

Also, there is no GUI lockups or hangs on Parthas build. For example, on official build when I’m on undo tab and click layers tab, or when I click Colors menu and choose any tool it may freeze GIMP for 10 seconds.

Test image for measuring was 42Mpix 16-bit TIFF. Using 8-bit JPEG was bit faster but not much.
My CPU is Ryzen5 1600, GPU is Radeon HD7700 series and I’m using Windows 7 64-bit. OpenCL was enabled on both builds.

22

Hi Bondde,

There is a bug report about this. Could you add to it with your message here?
https://bugzilla.gnome.org/show_bug.cgi?id=795880

I think the developers would like to know.

Cheers,
Daniel

23

Hello,
Try disabling OpenCL as it may be the cause. They disabled by default because it’s not good for everyone.
https://linuxfr.org/news/gimp-2-10-roule-au-gegl#accélération-opencl-et-multithread
Approximative translation :
“However, through the years we encountered crashes due to buggy graphic drivers, glitches (with nvidia drivers) or poor performances, particularly with “beignet” for intel cards.”