Georg Acher submitted a patch that greatly increased the speed of bumpmapping by getting and writing 32 rows at a time. Georg added that the performance issue was with gimp_pixel_rgn_get/set_row-calls in Gimp 1.2.1. Austin Donnelly suggested that most plugins should be using gimp_pixel_rgns_register() and gimp_pixel_rgns_process() functions instead, since they do blocking on a per tile basis. He suggested looking at whirl-pinch for examples of more complex access patterns. Ernst Lippe thought the speedup was caused by better caching, since it looks like all tiles are read and written gimp_tile_height (normally 64) times. Ernst submitted a patch that was similar, but allowed each tile to be read only once. He suspected that the algorithm could be rewritten so that only 3 tiles are needed at a time by using 3 extra buffer columns instead of 3 extra buffer rows. Kelly Martin noted that bumpmap.c calls gimp_tile_cahce_ntiles, which my not be asking for enough cache (or it could be a problem in the tile caching code.) Kelly also suggested using a pixel region iterator since the bumpmap need not be the same size on input and output.

Ernst Lippe offered to clean up some personal code that handled neighborhoods without fetching tiles multiple times. Austin Donnelly thought the core could use some tile convolution code, since it currently copies data Actually, the core could do with a tile convolution, since currently it copies data into a tempbuf before convolving it. This makes some tools more effificient (or incorrect) eg iscissors. Ernst had several design considerations

• What data type for the convolution matrix? the current core only seems to support integers, for my applications I found that floating points are really necessary.
• How to handle image boundaries? Treating pixels outside the image as zero gives in many case undesirable results, my code also supports mirroring but several other options are possible.
• What sizes of convolution matrices must be supported? This is an important issue. When you want to support larger matrices (e.g. 20x20) the most efficient approach is to copy the tile that you are processing and (parts of) neighboring tiles into a buffer and perform the convolution on the contents of the buffer. In this way the inner loops of the convolution can be much better optimized. When the size of the matrix is small (say 3x3) it could be more efficient to use the data from the tile directly (without copying) and to treat the boundaries of the tile as a special case.

There were no more posts in the thread

Georg Acher posted a patch to whirl&pitch to the list. The patch uses blocking to affect a 4.5x increase in performance without changing the main algorithm. Kelly Martin thought whirl&pitch used tile regions for this, but later responded that this was not that case and thought pixel regions might provide less of a loss due to locality. Georg noted that the locality was good between the source and destination, which was what really mattered. Ernst Lippe suggested that there were no major differences in CPU time between Georg's method and the old way. The differences lie in the number of calls to gimp_tile_get and gimp_tile_put. Requesting tiles from the main Gimp process is pretty expensive, it involves several context switches and a lot of copying. This is orders of magnitude slower than copying data within the plugin process from the tile cache to some other buffer. The whirlpinch plugin uses a cache size that is only big enough to handle the output tiles, there is no room for input tiles. This leads to a series of cache misses and horrible performance. Your modifications improve the cache-hit ratio because it [...] The more fundamental solution is to rewrite the algorithm so that it works on a tile by tile basis. In that case the minimum cache size is only 2 (for the output tiles) plus the number of input tiles that are needed to compute one output tile. Of course it is better to use a somewhat larger cache size because adjacent output tiles can use the same input tiles.

Georg also asked if there was a default tile size that helped caching. Kelly said the default tile size was 64x64, and that changing this made .xcf files non-transportable. I tried to modify the XCF loader & saver once to do reblocking, but it gave me a headache and I moved on to other, more interesting things, like feeding my cats. :)

Ulrich Windl had problems loading a .TIF image into the Gimp. The image had no progress bar and ended up rotated 180°. Ulrich wondered if the .TIF used LAB colors, not CMYK. He also mentioned something about a dialog box he didn't read. Ville Pätsi pointed out that the Gimp didn't currently have support for the CMYK colorspace, but it was planned for a 2.0.X release. Nick Lamb added [t]he dialog box who's contents you don't remember warned you that this would happen - read the warning dialogs!

Ulrich Windl's problem with .PNG files was as follows: The black pixels all appear white in Netscape, while in Amaya or xv the appear OK. I made PNGs the same way with older versions of GIMP, not having that problem. Simon Budig responded that this was a Netscape bug. The solution was to select black as background-color and check the "save background color" button in the PNG-Save dialog.

Sven Neumann posted the following note to the developer's list:

I have just committed a patch to the stable gimp branch that marks a few leftover strings for translations. Translators that are interested in getting a full translation into 1.2.2, update your po-files now!

Robert L Krawitz posted the following announcement about Gimp-Print 4.1.6: