tiles & memory

[Cyrille Berger]

> > Anyway, there is a possible optimization for symetric kernel, I might
> > play with it sometime. But we still need a faster general convolution
> > code :)
>
> We should, perhaps, investigate how Vips works for convolution. Vips is
> pretty fast and can handle really large images.

I know that what we do at work is two pass, one with horizontal convolution, 
and one with vertical convolution, and for a 600x400 image, what we call 
gaussian convolution is around 10 or 15ms on a PIV 3.2GHz. The two pass 
against one pass double the number of call to KisColorSpace::convolve, but 
for a 3x3 kernel a third of the pixels are need of each call, and more 
general for a nxn kernel, each call need only n pixels.

> > For 1.6, I have a possible solution, expand the API of colorspaces, and a
> > convolution function that takes an array of pixels instead of an array of
> > pointers of pixels. It would prevent around 80% of the memcpy, one other
> > advantage is the use of consecutive memory which might boost the
> > computation a little bit more, but I am not too willing to expend 1.6
> > API. (an other solution might be to keep the pointer of pointer, and to
> > move them in the grid, this solution spares around 60% to 70% of the
> > memcpy)
>
> Let's investigate that for trunk; but I guess that doesn't obviate the need
> for making it possible to keep chunks of tiles in memory, does it?
well the lock system is a better solution. And we really need a solution for 
1.6, I think I will do the second one, it's the less intrusive.

-- 
--- Cyrille Berger ---