Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-06 Thread Austin Donnelly
On Thursday, 5 Apr 2001, Georg Acher wrote: I just looked into bumpmap.c and tried to figure out if it can profit from blocking and played a bit with the code. It seems that there is some major (performance) problem with the gimp_pixel_rgn_get/set_row-calls in Gimp 1.2.1. The original

Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-06 Thread Austin Donnelly
Oops - I missed out some vital pixel region initialisation. On Friday, 6 Apr 2001, Austin Donnelly wrote: gimp_drawable_mask_bounds (drawable-id, x1, y1, x2, y2); for (y = y1; y y2; y += tile_width - (y % tile_width)) { for (x = x1; x x2; x += tile_width - (x % tile_width)) {

Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-06 Thread Ernst Lippe
The speedup that you see is probably mainly caused by better caching. There is a bug in the tile cache size for the plugin. The cache is under most circumstances too small and this means that every requested tile is not in the cache and must be transmitted from the main gimp process (SLOW).

[Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-06 Thread Kelly Martin
On Thu, 5 Apr 2001 23:55:57 +0200, Georg Acher [EMAIL PROTECTED] said: Hi, I just looked into bumpmap.c and tried to figure out if it can profit from blocking and played a bit with the code. It seems that there is some major (performance) problem with the gimp_pixel_rgn_get/set_row-calls in Gimp

Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-06 Thread Kelly Martin
On Fri, 06 Apr 2001 14:55:32 +0200, Ernst Lippe [EMAIL PROTECTED] said: Other improvements are still possible. I expect that it should be possible to rewrite the algorithm such that the tile cache contains only 3 tiles. From what I see the algorithm is the same in the horizontal and vertical

Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-06 Thread Ernst Lippe
Kelly Martin wrote: If the algorithm is pixel-by-pixel (each output pixel depends only on exactly one input pixel from each region being iterated over, and those regions are all the same size) there is absolutely no excuse not to use the pixel region iterator, which will automagically

Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-06 Thread Kelly Martin
When the output pixel depends on neighboring pixels (e.g. I strongly suspect that bumpmap uses a 3 x 3 neighborhood) the region iterator does not work very well. Not on its own. However, if you iterate the output region with the pixel region iterator, and use a pixel fetcher like the one in

[Gimp-developer] [patch] unbelievable speedup for bumpmap...

2001-04-05 Thread Georg Acher
Hi, I just looked into bumpmap.c and tried to figure out if it can profit from blocking and played a bit with the code. It seems that there is some major (performance) problem with the gimp_pixel_rgn_get/set_row-calls in Gimp 1.2.1. The original bumpmap took for my 1400*1400 image about 30s,