GNOME Bugzilla – Bug 165851
image-map tools could be faster
Last modified: 2005-02-02 17:14:03 UTC
After some recent discussion on gimp-user, I spent a bit of time investigating where the image-map are spending their time while previewing. There is no single place that takes up the bulk of the time, but there is a relatively simple change that, for me at least, yields about a 30% speedup in the preview-drawing. A patch is attached below. The change is basically to cause gimp_image_map_do() to process 10 tiles each time it is called instead of 1, and update the display only after the 10 tiles are done.
Created attachment 36785 [details] [review] patch for app/core/imagemap.c
I did the same investigation and even some benchmarks. I did a very similar change and didn't notice any speedup. Will try your change later today, perhaps it really makes a difference. My benchmarks clearly showed though that by far most of the time is spent in the actual colormap operation so there's where we should optimize. This can also be clearly seen without doing any benchmarking. Just compare the preview speed of the Curves tool with the preview speed of Color Balance. The former operation is performed a lot faster even though the tile iteration and preview code is exactly the same. The difference is that Curves is implemented using a LUT and can be performed a lot faster than color-balance.
Direct comparison showed that your change gives a tiny speedup so I have applied something that closely resembles your patch: 2005-02-01 Sven Neumann <sven@gimp.org> * app/core/gimpimagemap.c (gimp_image_map_do): tiny optimization based on a patch by Bill Skaggs. Process up to 16 tiles in one go before updating the display. Do we close this bug as FIXED now or do we want to keep it open to collect further improvements?
Hmm. I was testing using brightness-contrast on a 4000x4000 image, using a non-accelerated X server. In that situation, the patch gave a more substantial speedup. Not sure which are the relevant variables. (BC, like curves, uses a LUT, so the time in the actual operation is minimized in this test.) I think based on your comments the bug should be kept open. People use these tools a lot, so it is worth putting some effort into optimizing them.
Well, I think it should be closed. The benchmark clearly indicates that the optimizations need to happen in the individual tools. The GimpImageMap and GimpImageMapTool framework doesn't seem to be the bottleneck here.
Fine with me.