GNOME Bugzilla – Bug 512126
GIMPressionist takes a long time to load
Last modified: 2008-10-30 20:08:44 UTC
Please describe the problem: On a Mac with 1.66GHz Core Duo, 2GB RAM (and some free available), 7200rpm hdd, GIMPressionist still takes 9-10 seconds to open. During that time, GIMP uses about half of each CPU core if available. That in itself would be somewhat acceptable if it only happened once, but it also happens when the last tool I used was GIMPressionist, and I just want to use it again - another 10 second wait! Presumably, people on slower machines are suffering worse. It's not at all straightforward to see why GIMPressionist can't be kept in memory. Grateful for any insights you have on this. Thanks. :) Steps to reproduce: 1. Open GIMPressionist 2. Close it 3. Open it again Actual results: Expected results: Does this happen every time? Yes. Other information:
Obviously Mac OS X is a rather crappy operating system then. Perhaps you should file a bug report against Apple asking them to improve basic file I/O operations.
Your comment seems to be partly true. The windows version takes about 2 seconds (again, is that really necessary?) to load GIMPressionist on a slower CPU and hdd. Still, the problem could be avoided by keeping GIMPressionist in memory after first use. Unless this is some kind of anti-OS X partisan issue that I'm not aware of...
Plug-ins are separate programs, which communicate with Gimp using shared memory. So, starting a plug-in means starting a new program. When gimpressionist starts up, it reads a bunch of files, for its brushes, presets, etc. It is likely that this process is slow on your system. That's puzzling, though. When Gimp itself starts up, it reads at least 10 times as many files as gimpressionist, so if gimpressionist takes 10 sec to start because of file IO, gimp itself should take a couple of minutes. Presumably if that was happening, you would have let us know. In short, I think there must be something going on here that we don't understand. It's not clear to me how to figure it out without adding some debugging code to gimpressionist, though. There is one test you could do that would be informative. You could figure out where gimpressionist puts its resources (on a standard linux system, they go into subdirectories of /usr/local/share/gimp/2.0/gimpressionist), and you could delete or move aside most of them, leaving at least one of each. If it is really file IO that slows things down, then this should cause the startup to be much faster.
We have put lots of work into optimizing the startup of the GIMP application. Such optimizations have not been done for the GIMPressionist plug-in. So it is not very surprising that it performs worse in this regard. What's needed is some review of the file I/O code and perhaps some profiling.
I had a look at the code. The actual problem here is the way the preview is implemented in GIMPressionist. The whole source drawable is transferred to the plug-in and this is done in the most unefficient way.
I have some changes to the code in trunk that improve this significantly: 2008-01-27 Sven Neumann <sven@gimp.org> * plug-ins/gimpressionist/gimp.c (gimpressionist_main): transfer the pixels to the core on a tile-by-tile basis. * plug-ins/gimpressionist/gimp.c (grabarea): changed code that retrieves the source drawable to iterate over the data tile-by-tile. Improves GIMPressionist startup time (bug #512126).
To address this problem in the stable branch, a tile cache should help: 2008-01-27 Sven Neumann <sven@gimp.org> * plug-ins/gimpressionist/gimp.c: use a tile cache for better performance. Addresses bug #512126. Of course further improvements are possible. But the issue of this bug report should have been addressed well enough now. Closing as FIXED.