GNOME Bugzilla – Bug 141797
[TRACKING] GIMP is too slow ;)
Last modified: 2018-05-24 11:04:13 UTC
Of course GIMP isn't that slow, but having read some on-line articles I've seen this mentioned several times: rotating an image is slow compared to Photoshop, most plug-ins are slow compared to Photoshop', etc. It doesn't really matter if it's true or not, but we should try to change this impression that some people have. My proposal: use this bug report to track performance improvements. As a start I am going to measure the time that plug-ins take to complete after clicking the OK button. Using the default settings for each plug-in and a reasonably large image (say 1000 x 1000 pixels) I would say that 90 % of the plug-ins should finish within about 1 or 2 seconds on my old Athlon 700. Now I only need to find a way to profile plug-ins.
With a really minor change I was able to double the speed of the Sobel plug-in.
The emboss plug-in iterates through the image rows by using gimp_pixel_rgn_get_rect to get 3 rows at a time. However, it does so for each row, meaning that every single row is retrieved 3 times. Other plug-ins just get a single row at a time and do a bit of pointer shuffling to asign the previous, current and next row. This is probably a lot faster.
the whirl-pinch plugin restricts input to between -360 to +360 the two swirl scripts in Gimp that use whirl-pinch both call it repeatedly and I think it would be a common use case to want to swirl more than 360 degrees. if they could pass in 960 (instead of passing in 360 three times) it would mean less progress bars popping up which I think will at least make things smoother and improve the perception if nothing else, irrespective of any improvement in performance (although I am confident there will be some).
This would be a trivial extension. I'm pretty sure there are more plug-ins where we have such `low hanging fruit' and can improve the performance with a few minor changes. Right now I'm generating an overview of the performance of all plug-ins. As an (arbitrary) choice I use a 1000 x 1000 rgb picture representing a Picasso paining. I use the default settings for all plug-ins. Most plug-ins are pretty fast on my old system (Athlon 750). A few however, are slow. These are more complicated plug-ins like cubism and selective gaussian blur. They take 20+ seconds to complete. Due to their nature they will probably never finish in 1 second in my testcase, but halving the executing time may very well be feasable.
Another observation: for fast plug-ins (one second or less execution time) the progress bar updates form a large part of the execution time. For example the deinterlace plug-in takes 0.9 seconds with progress bar. Without showing progress it's just 0.4 seconds.
Created attachment 28041 [details] Gnumeric file with some performance data File contains some performance data for several plug-ins. Timing is the average of three measurements.
Created attachment 28042 [details] Picture used for measurements.
I have noticed that the thumbnail preview images in the Layers dialog get updated while scripts-fu scripts are running, whereas the main image does not update at all unless gimp-display-flush is called. It might be possible to slighly improve performance by postponing some of the updates to the layer thumbnails images.
Of course only the image update can be delayed until the display is flushed. The updates are already delayed as much as possible and I doubt there's room for a noticeable speedup here.
The Convolution Matrix has speed issues worth mentioning here. From: William Skaggs <weskaggs@primate.ucdavis.edu> To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Re: Re: Re: Blur plug-in The main reason not to use convmatrix is that internally it always does a 5x5 convolution, regardless of the matrix entries. This means it should take almost three times as long as the 3x3 convolution in blur.c; in fact, a little testing on a 5000 x 10000 image shows it taking over four times as long. Otherwise using convmatrix would probably be the right solution.
As was discussed on #gimp and on the mailing-list, convolution kernels should be applied in the core. GIMP should provide an API that plug-ins and scripts can use to do that. The convmatrix plug-in would then become a simple matrix editor and wouldn't perform the actual operation.
is the fact that gimp takes about 5 seconds to open a image window on my duron-800 relevant, or is that a gtk bug? it seems to be independant of the actual image: duplicate, new, paste as new, and new view all take equally long. If someone can tell me the origin of this problem i'm happy to try and make a patch for it.
I believe that is the time it takes the GtkUIManager to process the XML menu files.
Bug #143668 is about this issue -- it has been re-assigned to component gtk+. It isn't actually processing the XML files that takes time, it's building the menus. Anyway, nobody seems to be working on it actively at the moment, and I think it is an absolute blocker for Gimp 2.2, so it would be great if you could do anything with it. I have spent some time on it myself, and can confirm that it is a bastard. I think you'll need to be able to profile gtk+ calls to get anywhere.
Gimp 2.2.2, 450 MHz Mac G4, creating a new 400x300 RGB image, 6 seconds. (in case it isn't obvious, I consider this to be truly dreadful)
Albert, please note that bug #143668 is fixed in GLib and GTK+ for quite a while already.
I have just discovered another relevant bug: Having lots of images open slows the GIMP significantly (to the point where eyedropping lags on my 1.2ghz machine). This is true even if only a few of them are visible (2 are visible floating over the others, and 1 in a tabbed frame (the remaining image windows being the other tabs). The images are only small (48x48, 1 layer) and I had 20 open at one point -- eyedropping speed improved each time I finished with an image and closed it. Turning off 'Show selection' for the images which have a selection improves performance somewhat. I'm not sure what mechanisms window managers provide to inform windows of their (non-)visibility, but if possible, I think this could be addressed by only trying to animate the selection outline when it can actually be seen. There are periodic pauses as well as general slowdown in eyedropping, which is what led me to conclude that the selection animation is the culprit (since it runs on a timeout - 500ms is the marching ants speed I've configured, and that's roughly the interval between pauses.)
You have just "discovered" something that I addressed some months ago already (see http://svenfoo.geekheim.de/index.php/2006-09-05/the-gimps-asleep/). You also added a comment to a tracking bug, which is a very bad idea because all this bug should be doing is tracking other bugs.
Using an iMac 3.4 GHz, i7 chip 8 thread, 4 GB Ram. Snow Leopard GIMP 2.6.11 takes 11 seconds to start up. GIMP 2.8.2 takes 107 seconds to start up. Colour selection tool:- 3469 x 2642 px XCF file GIMP 2.6.11 takes less than 1 second to make a particular colour selection GIMP 2.8.2 takes 66 seconds to make exactly the same colour selection. I'm a graphics professional and while I love the creamy smooth new interface, I cannot yet use 2.8.2 for this reason. A colour selection may take 4 or 5 selection before you have what you want. Trashes the work pipeline. GIMP is marvellous.
John, I have an only slightly slower iMac, and things are really fast. GIMP starts in like 4 seconds, and nothing else feels slow either, so I guess you are seeing some real bug here, not this general slowness tracker. Please file s separate bug report, we should really sort this out.
Ah you already did, never mind.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/76.